feat: prevent HTTPs outcalls when stopping

[gregorydemay]

Sometimes a canister needs to make a dynamic number of HTTPs outcalls (e.g. scraping Ethereum logs) and this can prevent the canister from being stopped and hence upgraded. This is because when canister_stop is called, the canister is first entering the stopping state, which does prevent new calls to that canister, but does not prevent the canister itself from issuing new calls (see the specification on stop_canister).

This PR therefore introduces a new middleware CanisterReadyService that synchronously checks that the canister is running before delegating to the inner service.

[lpahlavi]

Thanks for the PR @gregorydemay, LGTM! Just some very minor nits for the tests from me.

[mbjorkqvist]

Thanks @gregorydemay! The ticket DEFI-2566 suggests adding a configuration option to the library, but I don't see that in this PR. I am thinking of potential use cases where a canister has some higher-level logic regarding HTTP outcalls that it may want to complete before stopping, in which case a configuration option would be useful for situations where the canister can be trusted to make the decision on whether or not to make HTTP outcalls while in the Stopping state.

[gregorydemay]

Good question @mbjorkqvist !

The ticket DEFI-2566 suggests adding a configuration option to the library, but I don't see that in this PR.

I had thought about this (initial commit had some new configuration field in Client) but my impression is that tower works best when having thin/modular layers that can be stacked on each other. Note that was you suggested is possible by using something like option_layer when instantiating the client or implementing one's own layer (possible wrapping the one from this PR). Does that make sense?