Optimized the use of the routing system in the REST module's entity support

Background

The REST module's entity support used to do access checking in the @RestResource plugin (the EntityResource class). This was done very early in the Drupal 8 development cycle: the rest module predates key portions of the Drupal 8 routing system! We never corrected this; we never went back to the REST module to make it use the routing system as intended.

What changed, why, and consequences

By optimizing this, access checking happens earlier, in the layer it is supposed to happen in, which hence sets the right example to follow in other @RestResourceplugins and reduces the risk somewhat (because now no controller is ever called when access is not allowed).

A nice consequence is that the 403 response is no longer cached by Dynamic Page Cache, because the routing system runs before Dynamic Page Cache. Response times are identical, without needing any of the I/O or cache storage — in other words: a nice scalability win!

This results in zero functional changes for 100% of users.

Recommendations for developers of overrides of the EntityResource class

If you've developed an override for a particular entity resource and you overrode the get(), patch() or delete() to add custom access logic, that will still continue to work; it just means you're most likely redoing the entity access checking that the routing system already did and then executing your custom access logic. Note that it is very strongly recommended to not customize access control logic in an override of the EntityResource class, but instead use the Entity Access API to consistently apply your custom access control logic to entities of that type in all circumstances.