runOrder unconditionally overrides junit.jupiter.testclass.order.default, replacing orderers configured elsewhere #3529

Affected version

3.6.0 (maven-surefire-plugin and maven-failsafe-plugin). The code on master behaves the same way.

Bug description

Reported downstream in quarkusio/quarkus#57084.

Since 3.6.0, JUnitPlatformProvider.setupRunOrder() maps the runOrder option to JUnit Jupiter ordering parameters and stores them with an unconditional put in the explicit configuration parameters:

• random -> junit.jupiter.testclass.order.default=ClassOrderer$Random and junit.jupiter.testmethod.order.default=MethodOrderer$Random
• alphabetical -> ClassOrderer$ClassName and MethodOrderer$MethodName
• reversealphabetical -> ReverseOrdering$ReverseClassOrder and ReverseOrdering$ReverseMethodOrder

Explicit parameters take precedence over system properties and junit-platform.properties, so any orderer that a library or the user configured through those sources is silently replaced when runOrder is set. Setting the same key through the configurationParameters plugin option does not help either: I checked that the runOrder mapping replaces it.

Before 3.6.0, runOrder did not translate into these JUnit parameters, so projects that combined it with a library-provided default orderer kept working.

A concrete case is Quarkus. quarkus-junit ships a junit-platform.properties that registers a ClassOrderer which groups test classes by test profile, because tests would otherwise run on an application that has already been shut down. With <runOrder>alphabetical</runOrder> and several @QuarkusTest classes using different @TestProfile, the Quarkus orderer is replaced by ClassOrderer$ClassName and the run fails. The Quarkus report is quarkusio/quarkus#57084.

Steps to reproduce:

1. Use maven-surefire-plugin 3.6.0 with <runOrder>alphabetical</runOrder>.
2. Add quarkus-junit and at least two test classes annotated with @QuarkusTest and different @TestProfile classes, whose names do not sort by profile.
3. Run mvn test.

Expected: the orderer configured by the library (or by configurationParameters) is kept, or the user gets a way to say which one wins.
Actual: the orderer is replaced by the one derived from runOrder.

Suggestion: only set these parameters when the key is not already present in configurationParameters, and document the interaction, building on #3510. I have not checked whether the provider can also detect values that come from junit-platform.properties at that point, which is what the Quarkus case needs.