Declare incompatbility with PHPUnit 9.3+

[sanmai]

This PR:

• Marks PHPUnit 9.3+ as non-installable together with Infection 0.17.x, with hopes that we'll sort these problems by 0.18.

Rationale is the following:

• PHPUnit 9.3 causes very nasty interop problems where Infection may work or it may not, and it is hard to understand what the problem is. This is a major inconvenience for our users.
• All the while PHPUnit 9.3 has very little new apart above mentioned incompatibilities. Only three or four new features and no critical issues resolved.

It is unfortunate that we have to do this, but if we care about our users, and if we want to save their time debugging this problem and waiting for a solution that may not come very soon, I think this is the best course of action for the released branch.

[maks-rafalko]

Absolutely agree. Thank you @sanmai

[maks-rafalko]

Ported to master 34671ab

had to recommit since cherry-pick / merge was impossible due to conflicts in lock file

[sanmai]

Fair enough. Thank you!

[Slamdunk]

Hi, in paratest we faced similar issues. Like infection, paratest needs deep knowledge about PHPUnit configuration, and many times we ended up with incompatibilities and bugs already fixed in PHPUnit XML handlers.
So in paratest I have decided for a steep turn: rely on PHPUnit classes to load and handle everything, even though they are marked as @internal:

https://github.com/paratestphp/paratest/blob/90b23bdddaa640837ea8af79ca522f72d02b96f2/src/Runners/PHPUnit/Options.php#L336-L338

Cons: we occasionally must pin exact PHPUnit version (although we still use caret operator to allow future versions), as something could break between patch versions.
Pros: no code, no maintenance, no bugs upon our shoulders.

I'm not telling you to do this as well; I just wanted to share the stress relieve of such solution.

[theofidry]

I believe you should also add this change to the version checker so that this applies to the PHAR as well

[rieschl]

Hi, is this really a problem with infection? PHPUnit 9.3 changed its configuration XML XSD, so users who use 9.3 should update their config. PHPUnit even notifies the user with a warning when an old config file was encountered and offers a migration tool.
Okay maybe the old config should have been marked as deprecated and not instantly be removed, but that's to be discussed in an issue in PHPUnit's issue tracker.

I run infection version 0.17.3 with PHPUnit 9.3.8 on multiple packages without any problems and no different behavior after updating.

Maybe we should reach out to @sebastianbergmann and the PHPUnit team and discuss re-adding the old entities into the XSD file? Or maybe infection could use an own internal phpunit.xsd to validate the schema?

[sanmai]

@rieschl yes, you can use a different schema, see #1283