Handshake refactor

[whyrusleeping]

I think the handshake method needs to be refactored and modularized. The default "handshake" should initially do nothing, but the program should register items to be negotiated. The rough algorithm im thinking is something like:

connect
swap peerIDs (tenative, maybe should be done after crypto)
send items to be negotiated (crypto, compression, services, etc)
for each item that both sides want, in order of hash or alphabetical order:
    send preferences
    select best or select compatible (depends on whats being communicated)
construct peer and conn objects
return

Im sure im leaving things out and not thinking of other things, but thats why im opening this discussion, i would like to openly collaborate and decide upon a good procedure for the handshake.

[jbenet]

Yeah, this needs work. Notes:

• "the other" handshake already happens first: protocol version checking (before secure channel)
• secure channel should happen on its own (maybe its first message embedded in the global handshake message, but this will be its own protocol, so separation of state)
• +1 on preferences, etc. we should build protocol suites/sets (like TLS does)