Refactor entire D3 graph

[K-Ho]

Using react-d3-graph contains way more functionality than we need, and is adding unnecessary complexity. I believe the best route forward would be to either greatly prune the codebase of react-d3-graph to the basics, create a d3-force graph from scratch, or start extending a much simpler library like https://github.com/uber/react-vis-force.

Think the last choice will be best + easiest

[K-Ho]

Current plan: create a d3-force graph from scratch.
The approach of both react-d3-graph or react-vis-force renders graph elements (svg circles and lines) in react's render() function and alters their x and y attributes with d3 (d3-force). This has both react and d3 handling the same DOM elements. This is ok, but could easily lead to bugs when bringing on new contributors - e.g. a new contributor adds a "cx" and "cy" attribute to circles in react's render function, causing ugly bugs from react and d3 handling the same parts of the DOM.

So, we'll be taking the approach of having react render a dumb container element with a ref in it's render() function. Then the entire network of nodes and connections is rendered in that container using just d3 (w/ enter, update, exit methods). We can build interactivity into the d3 rendered graph with event listeners.

[K-Ho]

• rendering nodes
• rendering links
• rendering messages
• clean layout
  centered (no),
  large (yes),
  responsive (no)
• Synced time between network sim and animations
• Pausing functionality
• Click on Nodes to spend/double spend

[K-Ho]

Current pausing is choppy. Potential Solution: Use a single transition per message send and pause
using the implementation (for the spiral) here: https://observablehq.com/@lemonnish/svg-path-animations-d3-transition. This does introduce a problem where if we pause right after a tick, restarting the simulation restarts the timer (doesn't wait the time), but the animation will pick up where it left off. Sandbox would need to keep track of time left before next tick, and add that in onResume before restarting the timer.

Other solution: keep current implementation, increase ticks, and optimize the way history is stored