Performance optimizations and memory management

Added some benchmarks to secure channel and played around with improving its performance, also started using a sync.Pool for message buffers.
Okay so this signed pipe does two things:
- issues challenge-response to ensure other end has access to the private key or is MITMing it.
- signs data going out + verifies sigs on data coming in.

It does not protect against replay attacks. a MITM only needs to MITM the challenge / response (or be 256bits lucky and have a stored signed challenge matching the issued challenge, which probably would never happen). The MITM can do the following:

- bob wants to talk to alice
- bob tries to talk to alice (really eve)
- eve, the WITM, fwds, bob's initial challenge as if she was starting the connection to alice.
- alice responds to eve, eve fwds to bob. 
- eve can then use previously acquired alice-signed messages to replay-attack bob. these don't even have to be from previous messages to bob, they can be to anyone. 
- OR, what's worse, eve can start a new connection with alice, and mimics every packet from bob, but signed as herself. eve can take alice's replies and send them to bob directly. Bob can continue to communicate with alice over eve, potentially extracting info bob wouldn't be sending, or manipulating their conversation.

While this signed channel doesn't encrypt and is thus cheaper for in-the clear messages, I recommend two changes. Im not certain this fixes everything, but is better, i think:

1. On sending the challenge, sign it before sending. the challengee must then sign a signed challenge. I.e. the communication is authenticated specifically between these two parties, at this time.
2. On sending the data messages to each other, use the challenge as a sequence number seed (a-la TCP), and verify incoming msgs match the expected sequence (C+1, C+2, ... ). this protects against replay attacks. the challenge space is large enough.
3. On sending the data messages to each other, ALSO include the ID of the connection (sender and receiver), to ensure the messages are part of the right session. While an attacker probably couldn't guess the right challenge number, they could eavesdrop, and initiate a session with the exact same challenge, and then fake responses. 
4. _**I THINK**_ we can XOR these three numbers together, so it only occupies one field: C_n XOR local.node.ID XOR remote.node.ID