The GossipSub protocol uses two streams, namely one from the local to the remote and one from the
remote to the local node. The rust-libp2p implementation enforces an upper limit on the churn of
both via `MAX_SUBSTREAM_CREATION`.

Thus far `self.outbound_substreams_created` was increased for every successful stream, but ignored
failed streams. Thus, on a given connection, a GossipSub handler could potentially indefinitely
retry creating an outbound stream, where each of those streams fails instead of succeeds to upgrade.

With this commit the handler tracks the number of requested outbound streams instead.

An outbound stream carries the first message for the remote node when upgrading in the
`OutboundOpenInfo`. Thus far the GossipSub handler would drop the message when the outbound stream
fails to upgrade.

This could e.g. lead to a remote peer receiving a GRAFT without a previous SUBSCRIBE.

With this commit the message carried in the upgrade's `OutboundOpenInfo` is re-enqueued.

Instead of popping messages early and having to re-queue them on error,
we can remove the use of `OutboundOpenInfo` and only send messages
in one place.

Hitting the max substream creation means something bad is happening.
This is worth reporting as `warn`.

- Split handler into `EnabledHandler` and `DisabledHandler`, reducing the amount of potential state
variants (e.g. protocol-not-supported but keep-alive-yes) and enforce the possible states at compile time.

- Return `DeniedUpgrade` when handler is disabled (i.e. `DisabledHandler`).

- Don't update `KeepAlive` across all handler methods, but instead derive it ad-hoc in
`ConnectionHandler::connection_keep_alive()` based on the state of the handler. Again reduces number
of possible invalid states at compile time.

- Remove INITIAL_KEEP_ALIVE. The default idle timeout is 120s. This should be plenty enough time to
establish in and outbound streams.

…eprecate/gossipsub-close-event

Co-authored-by: Thomas Eizinger <thomas@eizinger.io>