Re-architect Peer protocol

[mkrupczak3]

Currently Peers adhere to a strict call-response protocol where every "call" must be echoed by a "response" from the counter-party (and vice versa). Given that in Part 2 we are significantly changing the operation of the Peers, we will need to think carefully and implement a new protocol which may perform uni-directional messages.

Another consideration will be if the Peers are always listening for incoming connections from any IP, or if they will have a separate port for listening for Command-and-Control messages from the ServerRouter(s) detailing from which IP to expect an incoming connection from.

@trobe137 @mkrupczak3 @octapi345

[mkrupczak3]

It may not be necessary to have a separate port listening for Command-and-Control messages.

Instead, there can simply be a TCP port that is always listening for incoming connections. If I'm a Peer for example, I can assume that the counter-party Peer and Router will work out how to contact me by themselves without my intervention. The initiator peer can then connect to me directly using my address it obtained from the lookup

[trobe137]

Building on that, when a peer makes a successful connection, do we want it to stop listening and continue with the process? or do we want peers to sustain multiple connections? If we them to sustain multiple connections, we may want to build a PeerThread class. This class would handle the data processing and print the data we need regarding send-times...