Move cache lock timeout logic to CacheResultInterceptor

[gwenneg]

This PR lays some groundwork for #8631.

With the programmatic caching API in mind, I moved the cache lock timeout logic from the CaffeineCache implementation to CacheResultInterceptor since this is a feature that only makes sense while using the annotations caching API.

Please note that many things should change with #8631 if it ends up being merged, including the return types of all CaffeineCache methods which will all be async and rely on Mutiny. The purpose of this PR is only to move some misplaced code without changing anything to the cache extension behavior and performances.

@ben-manes: Could you please confirm this PR doesn't do any harm in terms of performances?

[ben-manes]

This looks fine to me. It's unfortunate that it has to be a blocking call, I suppose? If the return value was a future then it would be nicely asynchronous to avoid wasting threads, and you could use future.copy().orTimeout(...) for your timed get.

[gwenneg]

Thanks for reviewing this @ben-manes! I don't see how the blocking call could be avoided here unfortunately. Regarding future.copy().orTimeout(...), I don't think this can be used for now since Quarkus still supports Java 8 AFAIK and these CompletableFuture methods were introduced with Java 9.

[gsmet]

Could you avoid adding too many lambdas in runtime code? Thanks!

[gsmet]

General comment on this class: we try to avoid lambdas in runtime code.

[gwenneg]

Thanks for reviewing this!

I already knew about lambdas being the enemy in runtime code but there are only functional interfaces instances in this class (BiFunction for lines 35 and 51 and Supplier for line 76) which were already present before the PR (with a few differences). Are those nasty lambdas which should be eliminated as well?

[gsmet]

You can do it in a subsequent PR if you prefer but I would get rid of all the lambdas in this class.

[gwenneg]

I removed all lambdas from the extension runtime code, it should be good now.