Whether to capture keylogs (i.e., secrets) should only be decided by the
final binary that incorporates tokio-quiche somewhere in its dependency
graph. Using a feature allows any dependency to enable keylog capturing,
whereas a cfg flag must be explicitly set in RUSTFLAGS or similar.

I've opted to keep the feature flag around for now. We can remove it on
the next major bump and this makes the migration a bit easier.

`now_or_never()` can spuriously return None even if the underlying is
Future is ready.  This is due to tokio's cooperative scheduler returning
Pending if a task's coop budget is exhausted. We can avoid this by
wrapping the future in a `tokio::task::unconstrained()`

This was added in tokio 1.44 so we need to bump the minimum tokio
version required, and it's gated behing the "rt" feature as well.

Not entirely sure why this wasn't caught in CI before, but only by
`cargo package`.

Missed this in #1931.

The function was always logging a 1024 byte long buffer padded with
nullbytes. This doesn't look intentional, and may cause trouble for
some logger implementations that don't expect nulls in &str.

See also: rust-mobile/android_logger-rs#90

I checked the last 7 days of these logs. While there are a few ten
thousand of them, they were all instances of
`quiche::Error::InvalidPacket`. Those are not unexpected errors, so I
added an entry for them to QuicInvalidInitialPacketError.

No other unexpected errors were observed at all in the last 7 days. I
feel confident to remove the trial logging and pass those errors up to
users of tokio-quiche now.

So far, server-side `InitialPacketRouter`s that stopped with an error
(from the underlying UDP socket) closed without any notice. The only way
to observe this is through the `QuicConnectionStream` closing. To help
with debugging, this change adds an error log similar to the one we
already have for client-side connections.

- `min_rtt_us`
- `rtt_var_us`
- `bytes_unsent`
- `delivery_rate`

`bytes_unsent` has been added for compatibility with TCP sockets but it is currently not provided by quiche.

This partially reverts 3513025 as the change was found to cause
regressions on some internal deployments.

We used to always apply maximum `SocketCapabilities` to UDP sockets
passed into `connect_with_config()`. However, some NICs don't support
hardware GSO and Linux currently doesn't provide a software fallback. To
better support those setups, we now allow users to specify capabilities
manually in our connected `Socket` struct. This matches the interface we
have for server-side `QuicListener`s.

The default changes to not apply any capabilities to avoid surprises.
Client-side usage doesn't benefit as much from the capabilities anyway.

Our CI jobs run lints on rustdoc. Warnings and errors get inserted inline
into unrelated PRs, which is annoying.

This change fixes doc warnings as best I could figure out. Run locally
using:

```
cargo doc --document-private-items
```

…callbacks

It can be useful to tweak a specific connection's configuration based on
information like SNI. However this is only available after the client's
ClientHello is fully processed, which is not entirely apparent from an
application PoV (e.g. ClientHello can be split across multiple Initial
packets).

BoringSSL provides a number of callbacks called during the TLS handshake
and sometimes even before any packet has been sent (e.g.
`select_cert_cb`) which is useful to tweak congestion control settings
or transport parameters,  that provide the required information, but the
underlying quiche connection is not exposed to application code from
inside these callbacks currently.

This change adds a mechanism to allow applications to change specific
connection settings from inside these BoringSSL callbacks.