OPTIONS request to REST API does not return correct Accept header

[joehoyle]

The REST API should (and usually does) send an Accept header along with requests to tell the client what over HTTP verbs can be sent. This is determined by 1: the endpoint registration for those methods, and 2: by running the permission_callback on the endpoint to see if the request could run the request.

In the event of an OPTIONS request, which is the typical use case for wanting to see what requests can be accepted, we are not running the permission_callback on the endpoints, which means the Accept is not true.

This is a bug, caused by the shortcircuited routing in the OPTIONS request handling, specifically the matched_route is not set on the Response object, so the Accept handler can not determine what permission checks to run.

[joehoyle]

@rmccue I've removed the Accept header handling entirely from the OPTIONS request handler, and instead let that be ticket up by the function rest_send_allow_header. Also added unit tests for this.

Good news is we were only sending Accept (when we meant Allow) on OPTIONS responses, which were also not checking permissions checks. This means if someone was relying on Accept (when then actually wanted allow), the value they were relying on was likely incorrect too.

[joehoyle]

In 36829:

OPTIONS requests to REST API should return Allow header.

An OPTIONS request was incorrectly returning an "Accept" header which
was a typo of "Allow". This meant Accept was showing "GET, POST" for example,
however it was also not running the permission checks on the endpoints.

Instead, the correct route needs to be set on the request object, which means
the normal handling for the Allow header will kick in. This technically
breaks backwards compatibility, however given the value of Accept was also wrong
then this should not be an issue.

Fixes #35975.