Refactor: Move parsing into its own module

[carlaKC]

As is: we have a monolith main function that performs all parsing and creates a simulation.

Motivation: if using simln as a library, it would be nice to have a parsing module in sim-cli/src/parsing.rs to pull in some of the parsing/validation that main currently performs.

Some suggestions for things that we can pull out in a refactor:

• Cli: move into module so that it can be re-used externally
• SimParams: move to parsing module (it doesn't belong in the lib) (also move NodeConnection and ActivityParser)
• get_clients: builds the map of dyn LightningNode that'll be passed to the simulation
• validate_activities: performs ActivityParser -> ActivityDefinition conversion
• read_sim_path: this is a nice to have frill, might as well make it accessible for other folks

The only thing that's tricky here is that validate_activities needs to make calls to our dyn LightningNode to validate that pubkeys exist in their graph, so that needs to be threaded through. Ideally this could just be a generic closure that looks up the node, but it gets ugly when you start dealing with async closures (I briefly tried this in the past and gave up).

[chuksys]

I've been looking into this issue and noticed there's already some work started on the review-club-memleak branch in your personal fork. Would you recommend that I continue from the work done on that branch, or would you prefer that I start from scratch? I want to make sure I'm contributing in the most helpful way possible. Thanks.

[carlaKC]

Feel free to use the commits on that branch as a starting point (they're here unsquashed), but I think it would be good to take a look at it with fresh eyes - I did that in a rush for another project.

[f3r10]

Hi @chuksys, I had to complete this PR since I am working on #215. Let me know if you have already made some commits. Maybe we could collaborate on this PR.

[chuksys]

Hi @f3r10. Yes I have. We can def collaborate on this.