Make sure the testsuite doesn't fail when package installation order randomly changes

[jooname]

When running the testsuite, it sometimes fails to error like this:

ERROR: output differs from what is expected:
- EXPECTED
+ ACTUAL
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
 Scanning packages for orphan patches
 Validation completed successfully
 Processing patches configuration
-  - Installing vaimo/composer-patches-target2 (1.2.0): Mirroring from modules/composer-patches-target2
   - Installing vaimo/composer-patches-target3 (1.2.3): Mirroring from modules/composer-patches-target3
+  - Installing vaimo/composer-patches-target2 (1.2.0): Mirroring from modules/composer-patches-target2
   - Applying patches for vaimo/composer-patches-sandbox (1)
     ~ vaimo/composer-patches-sandbox: patches/multiple-packages-single-file.patch [NEW]
       Change: value17 => valueB; value5 => valueA
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑

It's not always, but it does happen randomly, requiring you to rerun the tests. This can be also a little annoying with Github workflows, even with fast fail strategy turned on.

Pre-requisites

1. Version 5.4.0 or above of vaimo/composer-patches
2. Any PHP version and any Composer version above 1

To Reproduce
No known steps yet

Expected
Even if a patch involves reinstalling multiple packages, the order of those should be irrelevant during the test.

Actual
When a patch involves reinstalling multiple packages, the order of installing those appears to randomly change, causing the tests to break.

Notes
This issue report is mainly a note to myself, but also a public notice that there can be this sort of issue when running the tests.

[jooname]

Some thoughts out in the open regarding this.

The problem is related to handling of promises in src/Repository/PatchesApplier.php::apply(). Verified this by checking if the order is already incorrect when the details are received from src/Patch/DefinitionList/Analyser.php::getAllTargets() and src/Utils/DataUtils.php::extractItems() but this wasn't the case. So the problem is with processing the promises from src/Compatibility/Executor.php::processReinstallOperation(). It would anyway add up, the randomness of the problem can be explained by the fact that promises are after all handled asynchronously/in parallel.

I guess handling each promise synchronously is one option, but definitely not preferable: it can show up in the speed of the patching and one might wonder what's the point of using promises here. Additionally since this problem is only relevant with tests, that sort of approach would be an overkill.

Preferably the solution would be done in the testsuite itself: is there a way for us to loosen up the checks? Currently the output checking is pretty strict, granted you can easily whitelist or even modify different patterns for individual lines as you wish. But not sure how would you tackle this specific case using those.

Would it then work to create a system for allowing passing alternative valid outputs? It would be a lot of duplication though, for example test/scenarios/default-event-install-partial-reapply/.output can be a bit awkward to duplicate only to switch around couple of lines and leave everything else the same. Not sure how would you deal with showing issues though, if neither output matches then based on which one do you show the differences?

Perhaps the first thing to try out is to simply replace this specific pattern with the right one. That in itself is simple, but would prefer to have it done in a way that wouldn't be tied to this exact pattern, but something that we could reuse in similar cases.