Feat/async network

[djrtwo]

Re-implement network is a collection of PriorityQueues one related to each validator.

• Network API:
  • send: send message to validator. message added to validators priority queue with delay
  • send_to_all: send message to each other validator.
  • receive: remove and return next available message from validators PQ. Return None if none currently available
  • receive_all_available: remove and return all available messages from validators PQ. Return [] if none
• casper.py and simrunner
  • added --network option for casper.py
  • SimRunner is a single-threaded sim runner, but we could now create a multithreaded sim-runner. Would need some sort of validator-container that was making decisions about making new blocks and polling the network thread for new messages.
• plottools
  • plottools do not show "communications" now. Instead they show new messages in the message's justification
  • gets pretty cluttered on integerplottool
• experiments
  • must specify network model in experiment jsons now
• TODO (this or another PR):
  • remove and/or rename some of the msg_gens because they no longer function as they should
  • built out msg_gen strategies based on goal block topology. each timestep, validators make decision on if they should gen a message based on what they are trying to achieve and what is currently going on. example: trying to get into a round robin
  • build out cooler Networks/delay_functions

QUESTION realizing send and send_all should probably include who is the sender. Right now, assumes message.sender is the sender for the delay function, but this is limiting if we want to model a more complex network and propagation (like gossiping). Thoughts?

(obviously validators could trick the network with this function exposed, but that access control maybe should exist in the simulation layer)

[djrtwo]

@naterush I wrote a bunch of in-line notes that might have been marked as "out dated" be sure to check those out.

[djrtwo]

@naterush realizing send and send_all should include who is the sender. Right now, assumes message.sender is the sender for the delay function, but this is limiting if we want to model a more complex network and propagation (like gossiping)

obviously validators could trick the network, but that access control maybe should exist in the simulation layer

[naterush]

@djrtwo had this realization as well w/ the last network PR. For now, I think there are two options that make sense:

1. Leave as is. There probably will not be a huge need for changing the sender for a while (we are going to have to add signatures, message validity checking, and the network will be hyper-realistic). So it seems not super high priority to me.
2. Add it in for now, but ignore access control (and say this comes later with signatures, or something). Just make it so validators don't lie.

I think 1 is fine for now - but let me know what you think.

[djrtwo]

@naterush @SeanAvery I suppose a threaded simulator that is controlling the network might override time with a clock... eh?

[djrtwo]

Generally ready to go. Still have StepNetwork...

Making a few issues around things to do related to this PR

[naterush]

@djrtwo last change, let's add back in either generated a gif or displaying by default. I'm fine with whatever for now, but something should happen by default (or we should change the make commands) to display or save.

[naterush]

Then LGTM!