chore: add test for CORS OPTIONS handler

[adamalton]

This is a follow-up from #1329, adding a test for the functionality that I broke. But it warrants a bit more explanation…

• The envAll middleware attaches a Logging instance to env.log. This should be a new instance for each request.
• The corsOptions function is not a middleware in the eyes of the itty-router, because it returns a response, and so the router then skips all other middlwares and just returns that response. This means that, if corsOptions is registered before envAll then the Logging instance is never attached to env.log and so when our main fetch function tries to call env.log.end(response) it dies trying to access the non-existent env.log property.
• BUT!... that problem only occurs if the OPTIONS request is the first request made to the server. If a GET/POST/DELETE/ request has already successfully completed then the env.log will already be set, and that will be reused for the next request thus causing:
  1. the problem to be silently hidden; and
  2. the old Logging instance to be reused, including all its metadata, which may include the User ID from the previous request 😱 . (This User ID is only used for logging purposes, so it's nothing disastrous, but it will cause us to log misleading information.)
• This little quirk means that the test I've added here doesn't catch the problem that was fixed in fix: swap the order of corsOptions and envAll to avoid error #1329 without the additional thing that I've added, which is…

I've made the Logging.end method blow up if you call it twice, thereby preventing it being reused on a second request. This seems to me like a reasonable solution, and it makes the test that I've added catch the problem that #1329 fixed. But alternative solutions could be:

1. Store the Logging instance on request.log rather than env.log, because the request is guaranteed to be new for each request.
2. Move to a more "proper" middleware setup, where there's a clear distinction between middlewares and handler functions, and where each middleware is therefore guaranteed to be run.

I'm happy to implement idea 1, if we think that's better, or to stick with the solution I've done. Idea 2 is probably beyond the scope of this PR.

[olizilla]

👍

cc @hugomrdias just so you know

[olizilla]

I want us to do

2. Move to a more "proper" middleware setup

at some point. but yes, we can land this fix and test before getting in to that.

[adamalton]

@olizilla do you have any particular thoughts around a better setup for the middleware stuff? It currently does all the right things, but I feel like it could perhaps just be a bit more explicit in the way things are declared. I don't have a specific proposal though. Maybe it's fine? Thoughts?