Context for Receipts and Manager methods #240
Description
There are multiple tests and even tap-manager methods that could benefit from having a context tied to that specific action.
For example, while we create a RAV request, we could have a transaction that could make all the actions atomic and in case anything fails, for example, one retryable check or even the RPC call to tap-aggregator, we could revert everything at once.
Another example is for checks that depends on information injected on other part of the code. Checks don't contain any other information other than receipt and we need a type of cache that adds more information to an specific receipt. With a context, we could add more receipt information to be used inside the checks.
Context should be used like Axum where we can inject into the "request" (receipt) or more broadly over the whole lifetime of the program (with_data() in axum's example).
This also solves a problem of having multiple Arc<Mutex<>>es and multiple copies of sqlx::Pool in all checks.