Add session_id accessors to Protocol and async Protocol

[YoganshSharma]

Add Protocol::session_id() to sync and async Protocol
Update round trip tests to verify both peers derive the same session ID
Fixes #61

[rustaceanrob]

#61 has already been resolved, closing

[YoganshSharma]

#61 has already been resolved, closing

Following up on this as @rustaceanrob previously mentioned this contribution was welcome
A downstream project relies heavily on this feature.
As outlined in the BIP-324 specification the session ID is specifically designed to facilitate channel binding and detecting MitM attacks, which is exactly why we need access to it. Without a getter on high level io::Protocol, we are forced to manually wrap or reimplement the lower level Handshake, which introduces unnecessary risk and potential for bugs.
This is a minor, read-only addition. If you are open to it, could we reopen this (or a modified version) to accommodate this use case?

[rustaceanrob]

Oh I see, it's not available on Protocol. I think we should add a newtype for this (SessionId([u8; 32]) since this will be a breaking change anyway. Otherwise this makes sense.

[rustaceanrob]

[u8; 32] is Copy I think it makes more sense to return an owned [u8; 32]

[YoganshSharma]

Since [u8; 32] is Copy, callers can always do *session_id.as_bytes() when they need an owned array. This avoids unnecessary copies and is convention (I looked at similar usage of as_bytes in bitcoin crate ). To return owned data conventionally to_bytes is used which consumes self.

[rustaceanrob]

At each callsite you've de-referenced it for use, which is some indication to me at least that callers will almost always want an owned version. In the case of primitives like u64, copying is almost always faster than a borrow. I can't imagine this copy would be very costly either. @nyonson do you have any opinion on this?

[YoganshSharma]

I can add to_bytes to return owned [u8; 32] similar to bip32::ChainCode ?

[nyonson]

I like where you have landed in 7804349, lines up with the C-CONV rule in the rust api guidelines which I wanna follow unless we have a real good reason not to.

[rustaceanrob]

ACK f874bc9

[rustaceanrob]

cc @nyonson for review and merge

[nyonson]

ACK f874bc9