Add a test for multiple contexts with Dune package management

[Sudha247]

This adds a test to show usage of multiple contexts, in the context of Dune package management.

The documentation was not super clear on how to do this. I've made some tweaks which hopefully makes it clearer, but I also intend to write a how-to guide for this with ThreadSanitizer and Dune package management as an example.

[rgrinberg]

I think this tests needs to be re-organized.

1. Running the solver is completely unrelated to using contexts. So if you're trying to exercise how contexts work, there should be no need to invoke the solver. These two features do not interact.

2. There are already tests that build multiple lock directories with multiple contexts. Your test should demonstrate something that is not already present in those tests.

[Alizter]

2. There are already tests that build multiple lock directories with multiple contexts. Your test should demonstrate something that is not already present in those tests.

Are you talking about per-context.t? That doesn't appear to be testing the multi-context build correctly. I was not able to find any others.

[Alizter]

@Sudha247 Could you split off the documentation changes from this PR. That should be easy enough to review. The test however should be changed like Rudi suggests to use a hand-written lock. This should be straight forward by just catting what the real lock generation gave and inlining it.

[rgrinberg]

2. There are already tests that build multiple lock directories with multiple contexts. Your test should demonstrate something that is not already present in those tests.

Are you talking about per-context.t? That doesn't appear to be testing the multi-context build correctly. I was not able to find any others.

If that test isn't testing contexts correctly, then fixing it is the way to go.

[Sudha247]

I’m happy to move the changes to the existing per-context.t test. However, the test’s intent seems clear: it demonstrates that a lock directory is attached to a context.

What I wanted to show, something the existing test doesn’t currently cover, is:

• Performing builds from multiple contexts.
• Showing that building different contexts pulls in the correct dependency chain via the dependencies specified in constraints.
• Showing that depopts added to the lock directory are carried over when building in that context.

After discussing with @Alizter earlier, we weren’t sure these things were working, so it seemed useful to add coverage for them in the test suite after we discovered they were indeed working fine.

[rgrinberg]

I don't mean to say that the tests in this PR are redundant, but that they need to be re-organized.

Performing builds from multiple contexts.

Great, this can be its own test.

Showing that building different contexts pulls in the correct dependency chain via the dependencies specified in constraints.

Constraints are only useful to the solver, so I'm not sure what you mean here.

Showing that depopts added to the lock directory are carried over when building in that context.

depopts and contexts also do not interact. depopts interact with the solver to produce lock directories. Lock directories interact with contexts. Testing this end to end is unnecessary and redundant.

Our tests should be focused on testing a single isolated feature or a particular interaction between features. So that if we break something, the test suite informs of what exactly is broken. We don't need more end to end tests because we already have way too many of them. We need tests that actually increase our coverage by testing parts that are not tested properly. There are tools (like ppx_bisect) to help with this, but I recommend to just get familiar with the kind of tests we already have.

[Sudha247]

Closing in favour of #13231.