Add test coverage to prove that REST resource's "auth" configuration is also not allowing global authentication providers like "cookie" when not listed

Actually, since this affects security, I think this is major.

Maybe it's once again possible to provide an upgrade path to ensure consistent behavior. We managed to do #2308745: Remove rest.settings.yml, use rest_resource config entities without breaking BC (i.e. without breaking configuration, i.e. without changing the behavior that depends on configuration — behavior was the same before and after). So perhaps we can find a way to do so here too.

I meant in #6 that #2308745: Remove rest.settings.yml, use rest_resource config entities also changed the config structure itself. We managed to provide an upgrade path for that. Hence why I think it's once again possible to provide an update path to ensure consistent behavior.

To be clear: in the update path, we'd automatically add all global authentication providers (cookie) to the configuration, to ensure we don't break existing sites.

#2808233: REST 403 responses don't tell the user *why* access is not granted: requires deep Drupal understanding to figure out landed recently. Which included the interdiff at #2808233-84: REST 403 responses don't tell the user *why* access is not granted: requires deep Drupal understanding to figure out. That added the following test coverage to \Drupal\Tests\rest\Functional\EntityResource\EntityResourceTestBase::testGet():

    $request_options[RequestOptions::HEADERS]['REST-test-auth'] = '1';

    // DX: 403 when attempting to use unallowed authentication provider.
    $response = $this->request('GET', $url, $request_options);
    $this->assertResourceErrorResponse(403, 'The used authentication method is not allowed on this route.', $response);

    unset($request_options[RequestOptions::HEADERS]['REST-test-auth']);

IOW: this already added some of the test coverage we need. But it's testing a non-global authentication provider What this issue is about, is ensuring that even global authentication providers are treated like this.

I worked on test coverage today to prove that global authentication providers are always allowed, even when they're not explicitly listed in a RestResourceConfig entity's configuration. Not being listed there causes it to also not be listed in a REST route's _auth option.

But… it turns out that actually the configuration is being respected after all! Did I really make the wrong observation way back when I opened this issue?

The ultimate test:

1. Install D8 Standard install profile.
2. Create an article: /node/1
3. Install the HAL, Basic Auth and REST modules.
4. While logged in, try GET http://d8/node/1?_format=hal_json. You get an error response.
5. Now modify rest.resource.entity.node, and add cookie to the auth key (by default, only basic_authis listed).
6. While logged in, try GET http://d8/node/1?_format=hal_json. You get a HAL+JSON response.

Tested this with both 8.2.6 and 8.3.x. It works as expected.

In other words:

1. this is not a WTF
2. this is not a security improvement
3. this is already working as expected!
4. hence this is a normal task, not a major bug
5. this does not need an upgrade path
6. … all this needs, is test coverage to prove it, to ensure we don't ever introduce a bug that changes this :)

Thanks!