Create response status code aliases on WP_Http for convenience

[joehoyle]

Throughout the REST API for response codes, we want to use aliased constants to be more clear in the code for each response code.

The best place to put these constants I think is WP_Http. This means in the REST API (and any other code) rather than specifying response codes directly (which is terse and opaque) one can use WP_Http::BAD_REQUEST for example.

[danielbachhuber]

Related #35425

[joehoyle]

Added missing status codes and docblock

[joehoyle]

In 36294:

Add response status code aliases on WP_Http for convenience.

These provide a more descriptive way to set response codes elsewhere,
so it's readable and less chance for the wrong response code to be
used such as 401 vs 403.

Props rmccue for the idea.
Fixes #35426.

[johnbillion]

The 1xx statuses are missing.

[johnbillion]

I wonder if these constant names need to be prefixed. CONTINUE is a reserved word in PHP so can't be used as a constant name.

Better: WP_Http::STATUS_CONTINUE, WP_Http::STATUS_OK, etc.

[rmccue]

@johnbillion That was actually intentional originally (I asked @joehoyle to leave them out), as it's almost impossible for those to get all the way up the stack. Additionally, you should probably never actually send them.

That said, we might want them for coverage. If we have conflicts with keywords, I'd prefer we special-case those specific ones rather than all of them.

[knutsp]

When introduced, they should be used globally, right?

Will it be considered "refactoring just because we can" if these constants was implemented in get_status_header_desc()?

If not, I can create ticket and patch.

[joehoyle]

@knutsp give that the descriptions already exist in get_status_header_desc i'm not sure how much value there is to doing that, but I don't feel strongly either way.

@johnbillion I think we'd be better not renaming all constants with STATUS_* just for CONTINUE, I'd rather we give 100 a description that isn't a reserved word.

[johnbillion]

Fixed in r36749