SSE Transport must be inserted before POST, so add convenience for using the DefaultServer

[StevenACoffman]

Replacement for #3153 to allow upgrade from POST request to SSE transport response

In order to enable the experimental Server-Sent Events (SSE) transport, you need to have the precedence before the POST transport, but many folks use the DefaultServer which only allows Adding (appending) transports.

This adds convenience methods to the server to both prepend (which is NOT appropriate for SSE) and a special one for inserting right before POST (which is ideal for SSE).

Signed-off-by: Steve Coffman [email protected]

[coveralls]

coverage: 56.585% (-0.07%) from 56.657%
when pulling 9f105d1 on sse_transport
into 1272aae on master.

[StevenACoffman]

@o8x @jmic @UnAfraid People who were using the NewDefaultServer were getting tripped up by an inability to add SSE support since it needs to be inserted in the middle of the transport precedence.

Currently, the server just picks the first available transport, and the NewDefaultServer orders them:

• Websocket
• Options
• GET
• POST
• MultipartForm

I did not just enable SSE for NewDefaultServer because when used over HTTP/1.1 (not HTTP/2), SSE suffers from a severe limitation to the maximum number of open connections of 6 per browser. See here

We might need to make our transport selection more sophisticated to enable default out-of-the-box support for SSE on HTTP/2 (or HTTP/3).

[UnAfraid]

@StevenACoffman I got bit by NewDefaultServer before, because it initializes Websocket transport and adding new one (To configure it) doesn't have effect, we could also deprecate it in favor of 'New'.
Alternatively we could add 'Priority' method on the transport and sort on add to avoid the POST before SSE.
Also on add if the transport already exists we could just replace existing one with the provided one