Rather than creating a blanket exception for SIM_ parameters, have a whitelist of known-undocumented parameters.
This will create a ratchet where new SIM_ parameters must be documented.
In the short period of time it takes for us to get organised/draining mavlink connections, the ArduPilot process might block writing to the primary mavlink connection - in which case we'll never get the message we requested.
Should solve
2022-08-31T23:17:43.6904119Z AT-0227.6: waiting for a message - any message....
2022-08-31T23:17:43.6904958Z AT-0227.6: Received (ATTITUDE {time_boot_ms : 3146, roll : 0.00013471684360411018, pitch : -4.076504410477355e-05, yaw : -2.1274349689483643, rollspeed : 6.679168291157112e-05, pitchspeed : 3.297374496469274e-05, yawspeed : 9.125166684498254e-07})
2022-08-31T23:17:43.6905505Z AT-0227.6: Waiting for mission count of (3) from (1:1) to (243:250)
2022-08-31T23:17:43.6905909Z AT-0227.6: Asserted mission count (type=2) is 3 after 0.100000s
2022-08-31T23:17:43.6906252Z AT-0227.6: Get first item on new link
2022-08-31T23:17:43.6906620Z AT-0289.2: Received exception (Did not receive MISSION_ITEM_INT
2022-08-31T23:17:43.6907047Z Traceback (most recent call last):
2022-08-31T23:17:43.6907386Z File "/__w/ardupilot/ardupilot/Tools/autotest/rover.py", line 3067, in test_rally
2022-08-31T23:17:43.6907719Z m2 = self.get_mission_item_int_on_link(
2022-08-31T23:17:43.6908080Z File "/__w/ardupilot/ardupilot/Tools/autotest/rover.py", line 2288, in get_mission_item_int_on_link
2022-08-31T23:17:43.6908469Z raise NotAchievedException("Did not receive MISSION_ITEM_INT")
2022-08-31T23:17:43.6908841Z common.NotAchievedException: Did not receive MISSION_ITEM_INT
2022-08-31T23:17:43.6909118Z )
2022-08-31T23:17:43.6909468Z AT-0289.2: Exception caught: Did not receive MISSION_ITEM_INT
This has been unused for a long time, and is getting in the way of reforms. Its position as a test rather than as a part of a framework was always going to cause oddities, particularly after we split the Copter tests into several chunks.