Restructure the composed store adaptors

[MathieuDutSik]

Motivation

We have the Journaling, ValueSplitting, LruCaching and MeteredStore but the potential is not fully exploited with a relatively large quantity of boilerplate code.

Proposal

The following was done:

• The get_name() function is introduced to the AdminKeyValueStore. Unfortunately, it was not possible to have a &'static str since we want to have composed types and so composed names.
• The introduction of the get_name() allows removing all the KeyValueStoreMetrics static variables and instead having a global store that contains the KeyValueStoreMeytrics.
• That global variable allows to put metrics for the AdminKeyValueStore trait function.
• The AdminKeyValueStore is added to all the Adaptor.
• For the LruCaching this requires the introduction of the LruSplittingConfig that contains the configurations in a nested way.
• The CommonStoreConfig is split with the cache_size being removed from it.
• The pub store are systematically changed into store in the adaptors.

Possible criticism of the design:

• There is no adaptor for the error types in the JournalingKeyValueStore. The rust difficulty was in the type Keys = K::Keys since this requires a nested key type and I think it was a little too complicated at this time.
• The KeyValueStoreMetrics were previously as &'static LazyLock<KeyValueStoreMetrics>. Now they are as Arc<KeyValueStoreMetrics>.
• There is no systematic adaptor for the error and config type, like e.g. LruSplittingError. But those would be pure boilerplate since for LRU, there is no additional error occurring.
• The input has not changed. The next step is in using YAML file for the input.

Test Plan

CI. Nothing should be affected by the refactoring.

Release Plan

Not relevant.

Links

None.

[ma2bd]

The cache_size belongs to a LruCacheConfig.

[ma2bd]

So compared to this PR, my idea was to replace DynamoDbStoreConfig by LruCacheConfig<DynamoDbStoreConfig> and rename DynamoDbStoreInternalConfig into DynamoDbStoreConfig.

[MathieuDutSik]

I understand. Indeed this PR does not implement that idea. However, that can be done next.

Thus the next step would be to remove the "Internal" attribute to the RockDb, ScyllaDb, DynamoDb and others. And they could then be exposed to users so that users could run, e.g. with ScyllaDb with cache or without.

But I think this can be done in a subsequent work.