Implement rate limit checking logic

[travis]

We need to put strict rate limits in place for all requests that don't have a valid authorization token. A sketch of how we can accomplish this with Cloudflare's Worker Rate Limits API can be found here:

https://github.com/storacha/freeway/pull/109/files#diff-9a117d52a8a2cb3e5f498575bdfdea4dc32418180c09029454fbaf7f95ebe5a1R82

This is related to the auth token logic - the existence of an auth token on a request will impact the rate limit logic:

#140

[fforbeck]

@travis I found this note about the accuracy of the Rate Limit API:

Accuracy
The above also means that the Rate Limiting API is permissive, eventually consistent, and intentionally designed to not be used as an accurate accounting system.

For example, if many requests come into your Worker in a single Cloudflare location, all rate limited on the same key, the isolate that serves each request will check against its locally cached value of the rate limit. Very quickly, but not immediately, these requests will count towards the rate limit within that Cloudflare location.

I guess this could be an issue if we need exact tracking of egress data for billing purposes. Is the goal to use the Rate Limiting API for general rate limiting while supplementing it with more accurate tracking mechanisms for billing, such as logging egress data in a database for precise accounting (e.g., accounting service)?

[travis]

such as logging egress data in a database for precise accounting (e.g., accounting service)

yea that's the basic idea - the rate limiting won't do any tracking beyond what Cloudflare uses in their backend (a black box to us) and we are willing to serve some requests that "should" have been rate limited - the "accounting service" will actually determine who gets charged for what, and should not charge users for data we serve over their predefined limits.

making this easier, for now, is the fact that we will not support user-defined rate limits for now - we'll rate limit requests with no "auth token" and won't charge anyone for them and will not rate limit requests with an "auth token" and charge the user who created that auth token for the requests.

[fforbeck]

The rate limiting check was introduced in this PR and is disabled by default across all environments.

For authentication, we’re using a bearer token, with the middleware verifying its presence in the Authorization header of incoming HTTP requests. While we may refine the token validation process in the future, this implementation establishes the foundation for the direction we want to take.