Re: #537: Remove segments (consensus call)

As I see it, END_SEGMENT is good semantics that does belong in a general
framing layer which is designed to carry protocols such as HTTP, Websocket
etc.

However, because we have conflated the protocol semantics with the framing
layer, for HTTP at least we are able to use frame type (eg HEADERs) in
place of END_SEGMENT to define semantic boundaries for proxies and
intermediaries.

So looking at this from an HTTP perspective only, they are not required and
we could live without them.   But I truly believe that our future is
multi-protocol and eventually we will learn that conflating the HTTP layer
with framing was a bad idea, and that we will eventually remove frame types
like HEADER, PUSH_PROMISE and CONTINUATION, and be left with only DATA
frames with segment semantics - which are more than sufficient to send
HTTP, Websocket, and other protocol semantics.

So my preference would be to keep END_SEGMENT and drop the conflation. But
as that is not going to happen, unless websocket is going to use
END_SEGMENT in the near future, then I guess it is best to drop it as
unused.

Note that I understand that websocket will be an extension, and thus it is
able to add END_SEGMENT semantics if needed - but this will need all
intermediaries to support the extension.  If we had not conflated the
layers, then many intermediaries would have been able to handle such
extensions without explicitly knowing about them - oh well, that's just me
crying over spilt milk.

-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.