[AMQ-9392] Prevent InactivityMonitor read check Timer leak when TCP connection fails

[asanguinetti]

Context

Whenever the InactivityMonitor TransportFilter is used in a scenario that would return false from AbstractInactivityMonitor#configuredOk, then the read check Timer is created but the call to startMonitorThreads exits prematurely, and the monitorStarted flag is never set.

Consequence

The class AbstractInactivityMonitor retains a strong static reference to the read check Timer created in startConnectCheckTast.
This reference cannot be removed even by calling stop on the TransportFilter, because stopMonitorThreads checks the monitorStarted flag before doing anything.
Also, stopConnectCheckTask does not cancel the Timer nor it removes the strong reference to it.
This reference to the Timer instance also implies a reference to the timer Thread, which will also retain the Thread Context ClassLoader (which may or may not be the same ClassLoader that loaded AbstractInactivityMonitor).

Expectation

If the AbstractInactivityMonitor fires up a Timer, there should be a way to dispose of it when it is no longer needed. It looks like it should happen when calling AbstractInactivityMonitor#stop, but it is not the case for this particular scenario.
Ideally there should be no Timer created if the connection is not properly configured (following the same logic as for the "monitor threads").

About this PR

This PR includes a simple test that allows for reproducing the issue to help maintainers with troubleshooting it.
Additionally there is a very naive solution proposed by someone who is a complete stranger with this library, so it should be examined very carefully (if even at all).

[mattrpav]

@asanguinetti thank you for the contribution, we'll look into it. Have you had a chance to test this change with the other transport (non-TCP/NIO) connectors (like stomp, mqtt.. etc)?

[mattrpav]

JIRA created: AMQ-9392

[asanguinetti]

@asanguinetti thank you for the contribution, we'll look into it. Have you had a chance to test this change with the other transport (non-TCP/NIO) connectors (like stomp, mqtt.. etc)?

@mattrpav Nope, I haven't. Do you believe this wouldn't be covered by your existing tests? If you guide me a little bit I can try to create the tests that may be missing.