Currently, there is a request rate limiting of 120/h on every swh-web api endpoints deployed to production.

This is problematic for the "/api/1/vault/directory/(dir_id)" and /api/1/vault/revision/(rev_id)/gitfast" endpoints.
Those endpoints accept both GET and POST requests. While the request rate limiting should remain in place
for POST requests (creation of vault cooking tasks), this should not be the case for the GET ones (check cooking tasks status).
For instance, the swh-web browse application query regularly the cooking tasks status through GET requests.
Once the request rate limiting is reached, no more cooking tasks status will be reported.

Even if it possible to define several requests rate limiting policy through some named scope on
the endpoints (see swh.web.common.throttling), there is no distinction made on the input request types.

So requests rate limiting implemented in swh.web.common.throttling should be improved
in order to apply different rate limiting based on the request types.