Parse HelloRequest and ClientHello messages

Incomplete, do not merge.
I finally found this part of the RFC:


   TLS allows extensions to follow the compression_methods field in an
   extensions block.  The presence of extensions can be detected by
   determining whether there are bytes following the compression_methods
   at the end of the ClientHello.  Note that this method of detecting
   optional data differs from the normal TLS method of having a
   variable-length field, but it is used for compatibility with TLS
   before extensions were defined.


and it is confusing as hell.

Is ClientHello situated inside of another wrapping struct that _does_ indicate a size of the message? If that's the case, we may be able to know deterministically if the client is sending extensions. It seems the alternative is that we must... wait some unspecified amount of time to see if the client will send some extensions? or, if the client sends some data that doesn't look like a list of extensions, we'll proceed assuming there are none?

Maybe if I understood the general state machine of TLS negotiating this would be more clear. Maybe I should find out how another TLS implementation does this.