Expose zero-copy-ish headers on ClientRequest

[maciejhirsz]

Alternative to #34.

I hope @tomaka can appreciate the number of hoops I had to jump through to get this to work properly. The way headers were previously parsed totally screwed with lifetimes here and prevented zero-copy header exposure (also the reason why path was previously an owned String).

What made this possible is realization that WebSocket handshake request does not contain body, thus we can safely borrow stuff from the buffer until a response needs to be sent (at which point buffer is cleared regardless).

Side effect: removed two allocations from request handling, not that it was a bottleneck, but hey.

BREAKING CHANGES:

• ClientRequest::path() will default to "\" if omitted in request (was empty string).
• ClientRequest::key() now returns WebSocketKey (alias of [u8; 24]), was &[u8].
• ClientRequest::into_key() is gone.
• Response::Accept's key field is now WebSocketKey (alias of [u8; 24]), was &[u8].
• handshake::Error has new variants.
• Server::receive_request() will only attempt to read headers up to 8KiB.

ADDED

• ClientRequest::headers() returns a new RequestHeaders struct with host and origin fields, exposing the Host and Origin header values (&[u8] and Option<&[u8]> respectively).

[maciejhirsz]

This mutable borrow of self.buffer prevented us from borrowing stuff in return value. The advance was not necessary since the buffer is never read after the headers (not just that, it should not contain any bytes after the request AFAIU).

[maciejhirsz]

Attempting decode after each read also made lifetimes convoluted since there is a mutable borrow to self.buffer made on every iteration. Opted to do a single parse after we are sure headers are complete in the new code.

[dvdplm]

This should work, nice job. :)

[tomaka]

I would have a lot to nit-pick, but I won't bother you more

[niklasad1]

ok, this will also emit an error if self.buffer.len() > MAX_HEADER_SIZE?

it's truncated below by std::cmp::min a couple lines above