TargetConnectionManager allows concurrent connections

[andrewazores]

Based on top of #359 - requires subprocess to not use its own independent TargetConnectionManager

This modifies the TargetConnectionManager to use a timed cache of JFRConnections, which by default expire (are closed and removed from cache) 90 seconds after their last access.

The advantage is that targeted requests taking place within a short time period of each other - such as a web-client user navigating around to see event templates, then creating a recording, then viewing a report, etc. - can generally use one long-lived connection between the ContainerJFR backend and the target, rather than opening and closing the connection on each user operation. This significantly improves responsiveness by removing a lot of latency from targeted API responses. This also allows for concurrent connections to multiple targets, whereas previously only one open connection to a single target was allowed, and requests would be blocked until the previous connection was closed.

---

Integration tests should be added to exercise the multi-target scenario in a consistent way, rather than simply by manual smoketesting. This will be much easier to do after #376 .

[andrewazores]

I added an integration test that tries to exercise this, although it's tough to write a test that specifically targets the concurrency. At the least it should verify that the new implementation does work as a drop-in replacement, however. The test will output the elapsed time, and in my test runs on my laptop it did become slightly shorter on average. The difference is not huge (~19s down to ~16s), but the requests fired in the test are also ones that should not take much time at all to execute to begin with, so any savings margin here is significant IMO. The test commit is at the beginning of the series, so it's easy to check out that commit and test the pre-PR functionality and test timing, and then to check out the last commit in the series to compare to the PR changes.

[andrewazores]

I added a few more steps to the integration test to verify the results a little more concretely, and as a side effect the total elapsed time on my machine went from ~22s pre-PR to ~16s post-PR, so the gap is widening the more API requests are issued. This points to a positive performance impact from the parallelism/concurrency enabled here.

[Alexjsenn]

I don't fully understand every last line, but I understand most of how the changes you made work. There is a significant time improvement for the Interleaved... test, and it all seems to work!