Previously, requests using a token that only had read_api access would
be treated as unauthenticated by the rate limiter. This ensures that
they are (correctly) treated as authenticated.

This does point to a general problem with the rate limiting code:
because it happens in a middleware before any application code, it's
hard to keep in sync with the different authentication methods the
application may allow. This applies to things like:

1. How the credentials are sent (Private-Token header, Authorization
   header, basic auth, etc.).
2. What credentials we accept (a personal access token, a personal
   access token with read_api scope, a job token, a deploy token, etc.).
3. Which endpoints those apply to.

The last one is mostly a concern for performance: we might pre-emptively
try authenticating using a method that isn't valid for a particular
endpoint. From a rate limiting perspective it doesn't matter so much, as
we're treating a request with valid credentials for a different endpoint
as authenticated for the current endpoint, which is wrong but not a
significant problem.