Don't fail closeFuture when an error occurs on closing (#487)

Strictly speaking, a `close` operation can't really fail (except when
the closing mode isn't supported or the channel is already closed). Even
if an error is encountered while closing a channel, or if an error
caused the channel to be closed, the end result is the same: the channel
will be closed.

In this case in particular, when streams are closed from the client
(i.e. by sending a RST_STREAM frame) the `HTTP2StreamChannel` would fail
the channel's `closeFuture`. This isn't appropriate however, as the
channel is successfully closed.

This change stops failing the stream channel's `closeFuture`. Instead,
if the close happens uncleanly, the error will be fired down the
pipeline and the `close` method's promise will be failed.

Add an article about multiplexing (#465)

Motivation:

It's hard to keep track of all the pieces that do multiplexing. When
making some changes I found myself writing down what each piece did and
how they fit together. I think this is generally useful information for
anyone maintaining the library.

Modifications:

- Add a DocC article about the different multiplexing approaches that's
aimed at _maintainers_ of NIOHTTP2.

Result:

Easier to learn about how multiplexing is done

---------

Co-authored-by: Cory Benfield <lukasa@apple.com>

Adopt `release.yml` (#452)

# Motivation

We want to start using the GH based release notes drafting to make it easier for publishing new releases.

# Modification

This PR adds the `release.yml` and configured the correct labels

Discard read bytes when accumulating continuation frames (#444)

Motivation:

When accumulating sequences of CONTINUATION frames, each frame is parsed
from a buffer. These bytes are read when the CONTINUATION frame is
parsed, but if more CONTINUATION frames follow then the buffer isn't
reset. This means that long sequences of CONTINUATION frames can result
in a larger than necessary buffer where most of the contents have
already been read.

Modifications:

- Discard the bytes of the accumulation buffer when transitioning back
  to AccumulatingHeaderBlockFragmentsParserState if more than half of
  the buffer has been read.

Result:

Lower memory footprint when parsing sequences of CONTINUATION frames.

Add a variant of configureAsyncHTTP2Pipeline which takes a stream del…

…egate (#439)

Motivation:

`configureAsyncHTTP2Pipeline` doesn't allow a stream delegate to be
specified. As the async pipeline uses the "inline" stream multiplexer
there's no way to account for streams within the connection channel.

Modifications:

- Add a sync and async variants of `configureAsyncHTTP2Pipeline` which
  accepts an optional stream delegate
- Rewrite the existing helpers in terms of the new one

Result:

Users can configure an async http pipeline with a stream delegate.

Avoid CoW while processing the next state when HTTP2FrameDecoder deco…

…des (#438)

Motivation:

CoWs appear when switching over the current state of the parser and holding it while also modifying it - inside `processNExtState()`. Following `append(bytes: ByteBuffer)`'s pattern, we should use a function that sets the state to an intermediary one with no associated data, before making the transformations.

Modifications:
- created the `avoidParserCoW()` helper function for the throwing functions
- used it in the switch cases inside `processNextState()`

Result:

CoW will be avoided when changing the state of the HTTP2FrameDecoder when decoding, so we won't have unnecessary heap allocations.

Adopt the Swift CoC (#398)

Motivation:

We're centralizing on the Swift code of conduct, so we'll x-reference
that instead of holding our own.

Modifications:

Hyperlink out to Swift.

Result:

Shared CoC across the projects.

Remove retroactive `CustomDebugStringConvertible` conformance in tests (

#425)

# Motivation
We had a retroactive `CustomDebugStringConvertible` conformance to `ByteBufferView` in one of our tests harnesses which caused compiler errors in the latest nightlies.

# Modification
This PR removes the retroactive conformance.

# Result
No more compiler errors.

DOSHeuristics DeadlineClock more explicit on 5.6 (#422)

Motivation:

The type inference system isn't able to work out the default clock type
in the DOSHeuristics init on Swift 5.6 so this change makes it more explicit

Modifications:

Add more explicit inits

Result:

The code should build on 5.6 and later

Merge pull request from GHSA-qppj-fm5r-hxr3

* Limit rate of permitted RST frames

Motivation:

Large number of stream reset frames may be used as a DoS (Denial of
Service) vector in an attempt to overload the CPU of the handling server.

Modifications:

Introduce an additional DoS heuristic which evaluates the rate of
incoming stream reset frames. If the rate exceeds that which is
permitted then the connection is closed and a `GOAWAY` issued.

The allowed rate is configurable but defaults to 200 resets within 30
seconds. This should be acceptable for most applications.

Result:

Excessive reset frames result in the connection being closed.

* review comments

* further review comments

* add integration test