Simulator: refactor and simplify InteractionPlan

[pedrocarlo]

Depends on #3775 - to remove noise from this PR.

Motivation

In my continued efforts in making the simulator more accessible and simpler to work with, I have over time simplified and optimized some parts of the codebase like query generation and decision making so that more people from the community can contribute and enhance the simulator. This PR is one more step in that direction.

Before this PR, our InteractionPlan stored Vec<Interactions>. Interactions are a higher level collection that will generate a list of Interaction (yes I know the naming can be slightly confusing sometimes. Maybe we can change it later as well. Especially because Interactions are mainly just Property). However, this architecture imposed a problem when MVCC enters the picture. MVCC requires us to make sure that DDL statements are executed serially. To avoid adding even more complexity to plan generation, I opted on previous PRs to check before emitting an Interaction for execution, if the interaction is a DDL statement, and if it is, I emit a Commit for each connection still in a transaction. This worked slightly fine, but as we do not store the actual execution of interactions in the interaction plan, only the higher level Interactions, this meant that I had to do some workarounds to modify the Interactions inside the plan to persist the Commit I generated on demand.

Problem

However, I was stupid and overlooked the fact that for certain properties that allow queries to be generated in the middle (referenced as extensional queries in the code), we cannot specify the connection that should execute that query, meaning if a DDL statement occurred there, the simulator could emit the query but could not save it properly in the plan to reproduce in shrinking. So to correct and make interaction generation/emission less brittle, I refactored the InteractionPlan so that it stores Vec<Interaction> instead.

Implications

• Interaction is not currently serializable using Serde due to the fact that it stores a function in Assertion. This means that we cannot serialize the plan into a plan.json. Which to me is honestly fine, as the only things that used plan.json was --load and --watch options. Which are options almost nobody really used.

• For load, instead of generating the whole plan it just read the plan from disk. The workaround for that right now is just load the cli_opts that were last run for that particular seed and use those exact options to run the simulation.

• For watch, currently there is not workaround but, @alpaylan told me has some plans to make assertions serializable by embedding a custom language into the plan.sql file, meaning we will probably not need a json file at all to store the interaction plan. And this embedded language will make it much easier to bring back a more proper watch mode.

• The current shrinking algorithms all have some notion of properties and removal of properties, but Interaction do not have this concept. So I added some metadata to interactions and a origin ID to each Interaction so that we can search through the list of interactions using binary search to get all of the interactions that are part of the same Property. To support this, I added an InteractionBuilder and some utilities to iterate and remove properties in the InteractionPlan

Conclusion

Overall, this code simplifies emission of interactions and ensures the InteractionPlan always stores the actual interactions that get executed. This also decouples more query generation logic from query emission logic.

[nyrkio]

Nyrkiö Report for Commit: a0c7abb

No performance changes detected.

Remember that Nyrkiö results become more precise when more commits are merged. So please check back in a few days.