Remove blank line after subscription headers

[toomim]

This implements https://github.com/braid-org/braid-spec/issues/85, and clarifies that there are only two levels of message framing in Braid subscriptions:

1. Updates
2. Patches

See https://github.com/braid-org/braid-spec/issues/85#issuecomment-1685374641

[toomim]

Potential problem: by removing the blank line, the first update returned by a server will be a valid GET response in itself, with a complete content-length, and I'm concerned that there may be a proxy in the chain of server->proxy->client that could think "I have a complete GET response body, now. Time to close this connection!"

If this is the case, it's possible that subscriptions might fail when run through various proxies. Perhaps the extra blank line could sufficiently confuse such a proxy so that it wouldn't try to kill the connection.

We would probably have to test subscriptions in a number of real-world scenarios to know for sure.

[toomim]

I tried implementing this in Braid-HTTP, and indeed ran into a problem— Chrome's implementation of fetch() kills the connection as soon as it receives a body satisfying the specified content-length.

This means that, unless we can find a neat hack around Chrome's behavior, we can't make this spec work within existing browsers.

I still think this is a great idea to consider in the future, but right now I think we should stick with the existing spec, which essentially "smuggles" multiple responses within a single response body, by inserting an extra blank line in the middle of the first response's headers before emitting content-length.

And for posterity:

• I was able to implement this in a node http server.
• I was able to make curl work, but had to explicitly set a transfer-encoding header with res.setHeader("transfer-encoding", '') or res.setHeader("transfer-encoding", 'chunked') on the server's response so that curl doesn't pay attention to content-length. Otherwise, curl also complained that the body length was longer than the content-length. Interestingly, curl doesn't care about the value of content-length; just that the header exists.

[toomim]

For now, I'm removing this from milestone 03.