Improve Logging Schema

[schampoux]

The purpose of this issue is to improve our current logging schema in order to get better feedback on failing gmx commands.

[schampoux]

Our current logging approach is handled primarily by the log_event function in folding/utils/logging.py file. The log_event function takes in an instance of the class it's being called from and an event dictionary. The function then prepares the event for logging by calling prepare_event_for_logging function from neurons/validator.py.

[mccrindlebrian]

To improve logging

1. primarily focused on improving the visibility on gromacs simulation events, and making sure that we catch any exceptions and log accordingly.

(potential) Solutions

1. Make the run_cmd_commands function into a method of a larger running class, that is able to hold the state of the particular command.
2. Have a method that returns some type of dictionary with potential simulation error events
3. This provides flexibility such that we can add the information to the event dict that is being passed through something like event.update(...).
4. Partially getting inspo from the Store class

[mccrindlebrian]

Deliverables

1. Pass commands
2. check the state of the running commands (success/fail). Some status market
3. Store the error(s) if there is one.
4. Take the class and turn into dictionary

[mccrindlebrian]

The most complicated part of this will be pipelining, which includes how to use the class throughout the codebase