Use ConcurrentHashMap#computeIfAbsent in JarCacheSupport

[basil]

While reading this code recently, I found some complicated logic to deal with a risk of multiple downloads of the same JAR getting scheduled, leading to special code to handle this race condition whose correctness is being challenged in #709. This complicated logic is not necessary if one instead uses ConcurrentHashMap#computeIfAbsent, whose Javadoc states:

The entire method invocation is performed atomically, so the function is applied at most once per key.

Due to these exactly once semantics, we don't have to worry about a race condition, so we can simplify the logic considerably, deleting the logic that is being challenged in the other PR rather than attempting to fix it. We also don't need the retry logic to deal with the executor rejecting the queue submission because (as an existing comment already notes) AtmostOneThreadExecutor never rejects submissions anyway (and any feasible replacement we might choose in the future would likely block rather than rejecting submissions).

Testing done

Ran mvn clean verify as well as running a job on an inbound agent with the Git plugin to load a lot of classes. Verified that the JAR cache was correctly populated after being purged.

[timja]

looks much simpler

[basil]

and any feasible replacement we might choose in the future would likely block rather than rejecting submissions

Foreshadowing the use of LinkedBlockingQueue in #717.