[Enhancement] Abstract StoreMetricsManager interface to support non-DefaultMessageStore implementations

[RongtongJin]

Before Creating the Enhancement Request

• I have confirmed that this should be classified as an enhancement rather than a bug/feature.

Summary

Abstract StoreMetricsManager interface to support non-DefaultMessageStore implementations

Motivation

Currently, the incTimerDequeueCount and incTimerEnqueueCount methods can only be called when messageStore is an instance of DefaultMessageStore. This creates a limitation for other MessageStore implementations (like TieredMessageStore, RocksDBMessageStore, etc.) that cannot access these metrics functionality.

The current code in TimerMessageStore.java uses direct type checking:

if (messageStore instanceof DefaultMessageStore) {
    ((DefaultMessageStore) messageStore).getDefaultStoreMetricsManager().incTimerEnqueueCount(getRealTopic(req.getMsg()));
}

This approach:

1. Breaks the Open/Closed Principle - requires modification of calling code for each new MessageStore implementation
2. Creates tight coupling - TimerMessageStore is tightly coupled to DefaultMessageStore
3. Limits extensibility - other MessageStore implementations cannot provide their own metrics strategies
4. Violates interface segregation - forces all MessageStore implementations to depend on DefaultMessageStore-specific methods

Describe the Solution You'd Like

Abstract the metrics management functionality into a StoreMetricsManager interface that can be implemented by different MessageStore types.

Benefits:

• Decoupling: TimerMessageStore no longer depends on specific MessageStore implementations
• Extensibility: Any MessageStore can provide its own metrics management strategy
• Backward compatibility: Existing DefaultMessageStore functionality remains unchanged
• Type safety: Interface ensures all implementations provide necessary methods

Describe Alternatives You've Considered

No

Additional Context

No