rewrite config & context, support tokio::main & tokio::test

[syphar]

This is a bigger refactor and I have to apologize in advance for the size of it. I have ~8 WIP branches where I tried to do only parts of the rewrite, but all failed and now I ended up doing many things at once.

The initial motivation of this is coming from wanting to make progress on the sync/async migration in our codebase. Plenty of things were and still are not in the state I want them to be.

For some parts I took inspiration from the crates.io codebase and how they do it, which I like.

To wrap it up, this PR:

• updates the Config struct to include a builder.
• changes the Context trait to a struct that just includes everything. This made much of the migration much easier, less lifetime errors.
• the places in the codebase that previously worked with a tokio::runtime::Runtime directly, now work with a tokio::runtime::Handle. This enables us to use tokio::test and also later migrate our main function to tokio::main.
• instead of the old test-wrappers, you can now just create a TestEnvironment in your test, and the cleanup happens in the Drop impl.

some detail notes about the implementation:

• I also tried bon because I like its design more, and crates.io uses it too, but since I wanted to "stack" the builder calls it was too annoying to work with.
• test diff is mostly: changes how to access the context content, or just whitespace / indendation, when I replaced the wrapper usage with the "new way".
• I only updated the tests that used override_config for now, some some selected ones. The rest follows later.

known limitations for now:

• the context is not lazy any more, which might slow down some tests, where test-setup is done that we might not need in the test
• default tokio::test doesn't work, it only works with flavor = multi_thread. This is because I want to use block_in_place to be able to teardown the test env in Drop. I took this from crates.io.

after this PR I imagine:

• renaming some methods on the context
• rewriting the other tests using the standard async_wrapper

[GuillaumeGomez]

We should also start adding some benchmarks as I think it's becoming more and more important.

[syphar]

We should also start adding some benchmarks as I think it's becoming more and more important.

for which parts?

in my mind, most of the time is still spent in the S3 fetch, so low-level speed doesn't really matter that much.

My focus is more around code-quality, readability, ...

( also I want to work on the subdomain/XSS part when it's easier to add :) )

[GuillaumeGomez]

All parts I guess? That would allow us to keep track of which part is taking how much time. Not sure how important it is though.

in my mind, most of the time is still spent in the S3 fetch, so low-level speed doesn't really matter that much.

Yeah I guess too. But having actual numbers to see if our changes start to take a bigger % would be useful on the long run.

My focus is more around code-quality, readability, ...

On that we both agree. Code quality comes before performance as long as performance is not problematic (and performance is not a problem currently).

( also I want to work on the subdomain/XSS part when it's easier to add :) )

Oh nice. :)

[syphar]

in my mind, most of the time is still spent in the S3 fetch, so low-level speed doesn't really matter that much.

Yeah I guess too. But having actual numbers to see if our changes start to take a bigger % would be useful on the long run.

we already see performance tracing numbers in sentry for that.

[GuillaumeGomez]

It gives details on what took time in a query or just tells how much time it took?