Feature/parallel multi event simulation

[mzaja]

I have implemented a feature which allows parallel simulation of multiple events by assigning them execution groups via event_groups argument to the market filter. Execution groups replace event ids in the simulated framework so that any combination of events can be executed in parallel, not just one event at a time. However, if event_groups mapping is not provided, event group defaults to event id, so the legacy event processing behaviour remains unchanged.

Example usage here:
https://github.com/mzaja/flumine/blob/34136cbbaa31b4d27b18e38bf8cbd7f25bcc998a/docs/quickstart.md?plain=1#L219-L224

[liampauling]

Any reason why you used this design

market_filter={"markets": [..], "event_processing": True, "event_groups": {"123": "A", "456": "A"}}

rather than:

market_filter={"markets": [..], "event_processing": True, "event_groups": {"A": ["123", "456"]}}

[mzaja]

My original intention was to name the feature "event_aliases" so that, for example, a forecast event ID is converted to the event ID of win/place markets. However, I thought that "event_groups" might be more descriptive and less confusing to work with.

I see two advantages of the dict approach over the list one:

1. It is not necessary to group all events. Say I want to simulate forecast, win and place markets in parallel. It is sufficient to map forecast event IDs to win/place event IDs. I do not need to explicitly map win/place event IDs to any group since groups default to event IDs if not provided. Think of this in term of "event ID alias is not provided so let's use real event ID".
2. The list approach requires iterating over all groups to find which event IDs are aliased. The input (event ID) and the output (event group) are reversed, which is clunky to work with. With the current implementation, it is easy to check whether any given event should be grouped (key exists) or not (key does not exist).

[mzaja]

Resolved merge conflicts with master.

[mzaja]

@liampauling So what do you want to do regarding this PR? Do you want me to update the API as you proposed or do you want to accept it as it is?