Shutdown quiesced conn managers when removed from pool (#2268)

Motivation:

In some rare situations the connection manager can leak a promise on
deinit. The connection pool maintains the refs to these managers and
they are only dropped in two situations:

1. when the pool is shutdown
2. when a quiescing connection is removed from the pool

When the pool is shutdown all conn managers are also shutdown (which
will complete all promises stored in its state).

When a conn is going away the conn manager relies on events from the
channel pipeline to inform it that it can close. When it closes the pool
will remove the ref to the conn manager and do a few bits of cleanup. If
the conn closes gracefully then all is well. However, if that isn't the
case then a reconnect may kick in (creating new promises). At this point
there is a conn manager attempting reconnects but which is no longer
managed by the pool: this is a bug in and of itself.

The conn manager is also kept alive by a ref from the channel it is
currently managing (via a channel handler), it's possible that at some
point during the connection lifecycle that that ref is dropped and
there's nothing keeping the conn manager alive, but this is speculative.

The fix for this is straightforward: for conn managers which are
quiescing shut them down when they are removed from the pool.

Modifications:

- Shutdown conn manager when its last connection is dropped

Result:

Fewer leaking promises

Bump version number to 1.27.0 (#2263)

Motivation:

We plan on tagging a release soon.

Modifications:

- Bump the version to 1.27.0

Result:

The version in the default user-agent string will match the released
version.

Add deprecation warnings (#2248)

Motivation:

v2 has moved to a new repo, grpc-swift-2. That's not all that
discoverable.

Modifications:

- Deprecate commonly used high-level types with a link to a forums post
explaining the move.

Result:

Users are notified about the move

Fix decompression of empty messages with a ratio limit (#2246)

Motivation:

The decompressor has a decompression limit to protect against zip bombs.
This can either be absolute or ratio based. It's also possible in gRPC
for a zero length message to be marked as compressed. gRPC attempts to
decompress the zero length message and fails (because zlib wants a
non-zero sized buffer and gRPC won't give it one as the limit is the
buffer size is limited by the `ratio * msg_size` which in this case is
zero).

Modifications:

- If the input to decompress has no length, skip decompression
altogether

Result:

- Can decompress zero length payloads with the ratio limit
- Resolves #2245

Allow padding to be omitted from binary metadata values (#2243)

Motivation:

Binary metadata values are encoded as base64 strings. The gRPC spec
doesn't require that the values are padded. Currently gRPC Swift
requires values to be padded otherwise decoding will fail.

Modifications:

- Allow padding characters to be omitted when decoding base64

Result:

Can decode unpadded binary metadata values

Normalise CI flags (#2240)

Motivation:

`-require-explicit-sendable` is ineffective without `-Xfrontend` but
combining it with `-warnings-as-errors` surfaces a warning from SwiftPM.

Modifications:

- remove `-require-explicit-sendable`, it's not doing anything
- add `-require-explicit-availability` to nightly jobs

Result:

More consistent CI flags

Generate availability annotations (#2232)

Motivation:

gRPC is moving from specifying the platforms in the package manifest to
annotating code with availability annotations. In order to do this the
generateed code must also be annotated.

Modifications:

- Generate appropriate annotations

Result:

Generated code has availability annotations

---------

Co-authored-by: Gus Cairo <[email protected]>

Bump version number to 1.26.0 (#2236)

Motivation:

We plan on tagging a release soon.

Modifications:

- Bump the version to 1.26.0

Result:

The version in the default user-agent string will match the released
version.

Update version to 1.25.0 (#2227)

Convert errors thrown from interceptors (#2209)

Motivation:

gRPC checks whether errors thrown from interceptors are `RPCError` and
otherwise treats them as `unknown` (to avoid leaking internal
information). There is a third possibility: the error is explicitly
marked as being convertible to an `RPCError`. This check is currently
missing when thrown from client/server interceptors.

Modifications:

- Catch `RPCErrorConvertible` in the client/server executors when thrown
from interceptors
- Add tests

Result:

Error information isn't dropped