* Adds support for indicating to downstream Service impls that a certain number of bytes should be reserved (to make space for adding a TSIG RR or EDNS options during middleware post-processing).
* Adds support for strongly typed passing of arbitrary metadata between middleware that produces a type and middleware that consumes the type (e.g. passing the used TSIG key name from TSIG middleware to XFR middleware).
* Replaces the blanket impl Service for Arc with a more general impl Service for Deref.
* Removes the blanket impl Service for fn as I have multiple times been blocked from defining some other Service impl because the fn one matches, because its presence can cause very confusing compiler error messages if your impl Service for T is not quite in sync with the signature of your other impl T blocks.
* Adds an "enabled" flag to the CookiesMiddlewareSvc making it easier to create a service stack with optionally enabled layers based on runtime configuration.
- Re-enable the cookies Stelline test and fix `CookiesMiddlewareProcessor` to allow requests with invalid cookies to proceed if they are authenticated or not required to authenticate.
- Add support for net blocks in the deny list of the cookie middleware processor, ala Unbound, otherwise the deny list is difficult to use beyond a few simple specific IP addresses.
- Improvements to the Stelline server test support needed by the Stelline cookies test:
- Advance mock system time in the Stelline server tests.
- Move Stelline server tests under src/ to permit #cfg(test) based swap out of real system time for mock system time.
- Use the thread_local version of mock_instant to ensure parallel mock time dependent tests don't interfere with each other (such tests also use tokio::time which only works if they run in a single thread).
- Set mock system time to start at zero for each Stelline server test (as expected by the cookies .rpl test script).
- Pass the IP address of the test client to the server so that the cookies middleware can match it against its deny list.
This PR proposes a revised policy for dealing with minimum supported Rust
versions.
It suggests to keep the rust-version field in Cargo.toml at the oldest Rust
version that is able to build with minimal dependency versions and all
features enabled. In addition, the Rust version necessary to build with
latest dependencies is provided in the README and as a comment in
Cargo.toml. Both these versions are checked in the CI workflow.
The reasoning behind the proposal is that rust-version sets a hard limit on
the version, so it should be chosen as low as possible. While technically it
could be lower with a subset of the features selected, this feels like a
slippery slope and setting the version with all features selected feels like
an acceptable compromise.
Only documenting the version that is necessary to build with latest
dependencies isn’t ideal but at least provides some guidance as to what to
choose for people who go look for some.
