Fix OTel agent detector test that was polluting the JVM for later tests

[tjquinno]

Description

Resolves #8448

Some pipeline runs and some developers' local builds experienced reliable failures, other pipeline runs and developers saw no problems.

There had been some conjecture that some static storage was contributing to this problem.

Instead, the problem turned out to be a bug in the AgentDetectorTest class.

Background

Our AgentDetector examines config and system properties (and the OTel context) to try to determine if the OTel agent is present. Our OpenTelemetryProducer uses the AgentDetector to decide whether to use the OpenTelemetry instance that the agent will already have set (if the agent is present) or to initialize and set an OpenTelemetry instance according to current config settings (if the agent is absent).

Some of our tests use an in-memory TestSpanExporter to see if spans were managed as expected. The use of this test exporter is conveyed through configuration that is set at test-time and so will not be used if the agent is detected.

The problem

The AgentDetectorTest set a system property to make sure that the detector correctly responded, but the test did not reset or clear the system property after the test.

If the agent test ran before other tests that depended on our custom in-memory collector, the later tests would fail because tests would skip using the configuration to prepare OTel and, therefore, the in-memory collector. Because span data would not be sent to the in-memory collector in those cases, tests that expected span data in order to check it would fail. The non-deterministic ordering of test execution explains why some builds saw failures while others did not.

The fix

The PR changes the AgentDetectorTest to restore or clear the system property at the end of the test to avoid disrupting later tests.

The PR also removes the changes to the surefire plug-in config that forces tests into their own JVMs since that workaround is no longer needed.

I verified the problem and the fix by temporarily forcing the order of the tests so the agent detector test preceded at least one of the tests that failed.

Documentation

No impact.

[ljnelson]

Consider, rather:

<systemPropertyVariables>
  <otel.bsp.schedule.delay>${otel.bsp.schedule.delay}</otel.bsp.schedule.delay>
</systemPropertyVariables>

…and, elsewhere in the pom.xml:

<properties>
  <otel.bsp.schedule.delay>100</otel.bsp.schedule.delay>
</properties>

[tjquinno]

Fixed