Compute cache value on calling thread to fix thread starvation

[gwenneg]

Partially fixes #13158.

Deadlock should no longer happen when the lock timeout feature from the cache extension is not used. In that specific case which is probably the most common way to use the extension, the cache value computation is now done synchronously from the calling thread.

Deadlock can still happen while using both the lock timeout feature and the context propagation extension.

This was tested using JMeter and the reproducer provided by @sivelli. I reproduced the issue locally with 1.9.2.Final and it's gone with this PR.

[gwenneg]

I'm making this a WIP until tomorrow. The lock timeout enabled case can be treated the same way as discussed in #13158.

[gwenneg]

All cache values computations are now done on the calling thread in a synchronous way. This means the cache extension no longer needs context propagation, so I removed the ManagedExecutor from CaffeineCacheBuildRecorder.

I also removed some code that was used to prevent Caffeine from logging warning messages when an exception was raised during an async cache value computation. It was no longer needed since there's no async computation anymore.

This PR is ready for a review.

[gwenneg]

@gsmet Assuming the PR is merged with the current code, it may be worth mentioning in the release note that the cache extension no longer needs the context propagation extension.

[gwenneg]

Last minute push: since ManagedExecutor is gone, caches can now be initialized at ExecutionTime.STATIC_INIT instead of RUNTIME_INIT.

[gsmet]

@gwenneg I wonder if we should backport this to 1.10? It looks safe enough and fixes an annoying issue.

WDYT?

[gwenneg]

@gsmet Yes, I think this should be backported not only because of the thread starvation fix but also because this new version should be much better in terms of performances.

[gwenneg]

Commit message changed to better reflect the PR content.

[gsmet]

Thanks for the quick turnaround!

[gwenneg]

Thanks @ben-manes for your help with this!

[ben-manes]

If the loader throws an exception, does it complete the future? It doesn’t appear to, which would cause the in-flight future to remain in the cache and block subsequent readers. I might be misreading but can you please verify?

[gwenneg]

There was indeed an issue with exception handling that was fixed in #13410.

[ben-manes]

oh! I forgot about that, thanks!

[gwenneg]

Thanks for alerting me here!