Handle close code&reason in libp2p-websocket

[dvdplm]

When a websocket is closed the closer may provide a code and optionally a reason for why the connection was closed (see rfc 5.5.1 and rfc 7.1.6 for details). Currently libp2p does not propagate this information to applications.

On the lower layer, soketto supports returning reason code](https://github.com/paritytech/soketto/blob/c02379dead28966a50c34dc4b2a6887d52c7ccd2/src/connection.rs#L365-L379) (but the user data is tossed away here).

We could change IncomingData to include a Close variant that carries the reason code&string and make sure the stream is closed properly after a Close frame was received.

The motivation for this is substrate-telemetry where an overloaded websocket server could use a way to tell connecting clients to back off, using the 1013 Try again later, or to inform them they are not allowed to connect at all using the 1008 Policy violation codes. Currently, clients connected using libp2p-websocket get a generic std::io::Error along the lines of Error: Custom { kind: Other, error: B(Custom { kind: Other, error: Closed }) } after a remote hung up on them.

See here for a full list of (semi-)standard status codes.

[dvdplm]

On the lower layer, soketto supports returning reason code](https://github.com/paritytech/soketto/blob/c02379dead28966a50c34dc4b2a6887d52c7ccd2/src/connection.rs#L365-L379) (but the user data is tossed away here).

This is incorrect. soketto currently does not make the CLOSE frame reason code available to users. The code referenced above extracts the reason code to build a response CLOSE message (which is according to spec: the party receiving a CLOSE message must echo it back, https://tools.ietf.org/html/rfc6455#section-5.5.1), but cloaks the reason code/application data to calling code.

[mxinden]

If I am not mistaken, this is fixed via #2319. I am closing here.