Introduce cache injection and NoOpCache

[gwenneg]

This PR lays some groundwork for the programmatic caching API (#8140). The vast majority of the changes here come from #8631 and has been discussed there already. I recently added NoOpCache which hasn't been reviewed though.

So why create a new PR instead of keeping all this in #8631? For two reasons:

• I had a talk yesterday with @phillip-kruger about some enhancements (stats for example) he wanted to submit for the cache extension and these enhancements require the ability to inject a cache (which was already developed in Introduce programmatic caching API #8631).
• Most of this PR content is about internal implementation, it only contains one annotation and two interfaces which will be part of the programmatic API: @CacheName , Cache and CacheManager. I didn't put in this PR any of the API methods from Introduce programmatic caching API #8631 related to cached data (data retrieval or invalidation) since it was still being discussed. That's why the Cache interface is empty for now. @phillip-kruger will probably be the first one to add a method in this interface.

This PR does not change anything in terms of behaviour for the annotations caching API when the extension is enabled. When it is disabled, the only change is the introduction of NoOpCache. The old way to disable the extension at build time wasn't compatible with the programmatic API, hence this new type of cache.

This PR does not contain any change to the doc, that's intentional. I don't think we should document the programmatic API or the ability to inject a cache before there is at least one method in the Cache interface.

I think this can be merged even if #8631 is still a WIP with a few open discussions as long as @CacheName , Cache and CacheManager are accepted as new members of the undocumented caching API (it seemed OK in #8631).

[gwenneg]

Here are a few code examples to help validating the programmatic caching API elements from this PR:

▶️ Field Cache injection

@ApplicationScoped
public class MyService {

    @CacheName("my-cache") // @Inject can be used but is optional.
    Cache cache;

    public void doSomething() {
        // Use future programmatic caching API method e.g. cache.getStats()
    }
}

▶️ Constructor Cache injection

@ApplicationScoped
public class MyService {

    public MyService(@CacheName("my-cache") cache) {
        // Use future programmatic caching API method e.g. cache.getStats()
    }
}

▶️ Field CacheManager injection

@ApplicationScoped
public class MyService {

    @Inject
    CacheManager cacheManager;

    public void clearAllCaches() {
        // Let's suppose for this example that Cache.invalidateAll() is added in the future
        // (it is not available right now)
        Collection<String> cacheNames = cacheManager.getCacheNames();
        for (String cacheName : cacheNames) {
            Cache cache = cacheManager.getCache(cacheName);
            cache.invalidateAll();
        }
    }
}

[gwenneg]

cc @emmanuelbernard @galderz

[gsmet]

I just added one small question.

[gsmet]

You allow it for methods here but you don't check the method case in the processor. Is it normal?

[gwenneg]

Good catch! It is allowed on methods because of CacheProducer but I should add a check in CacheProcessor to forbid the annotation on any other method than the one from the producer.

[gwenneg]

I made the following changes:

• rebase on master to fix conflicts
• new check in CacheProcessor: @CacheName is now only allowed on methods from io.quarkus.cache.runtime.CacheProducer
• injection tests coverage improvement

Despite the targets of @CacheName and the new check, it is possible to inject a cache using that annotation at all CDI usual injections points: fields, constructors parameters and methods parameters. These are all tested in this PR.