[Bug] TieredMessageStore#getOffsetInQueueByTime impl miss argument boundaryType

[GabrielDUX]

Before Creating the Bug Report

• I found a bug, not just asking a question, which should be created in GitHub Discussions.

• I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.

• I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.

Runtime platform environment

Any platform.

RocketMQ version

introduced incommit 215b8de

JDK Version

JDK 1.8

Describe the Bug

    @Override
    public long getOffsetInQueueByTime(String topic, int queueId, long timestamp, BoundaryType boundaryType) {
        boolean isForce = storeConfig.getTieredStorageLevel() == MessageStoreConfig.TieredStorageLevel.FORCE;
        if (timestamp < next.getEarliestMessageTime() || isForce) {
            Stopwatch stopwatch = Stopwatch.createStarted();
            long offsetInTieredStore = fetcher.getOffsetInQueueByTime(topic, queueId, timestamp, boundaryType);
            Attributes latencyAttributes = TieredStoreMetricsManager.newAttributesBuilder()
                .put(TieredStoreMetricsConstant.LABEL_OPERATION, TieredStoreMetricsConstant.OPERATION_API_GET_OFFSET_BY_TIME)
                .put(TieredStoreMetricsConstant.LABEL_TOPIC, topic)
                .build();
            TieredStoreMetricsManager.apiLatency.record(stopwatch.elapsed(TimeUnit.MILLISECONDS), latencyAttributes);
            if (offsetInTieredStore == -1L && !isForce) {
                return next.getOffsetInQueueByTime(topic, queueId, timestamp);
            }
            return offsetInTieredStore;
        }
        return next.getOffsetInQueueByTime(topic, queueId, timestamp);
    }

The next.getOffsetInQueueByTime(topic, queueId, timestamp); calling missed the argument boundaryType.
The API SEARCH_OFFSET_BY_TIMESTAMP may become inoperative when the boundaryType argument is missing. This occurs if the message is not found in tiered storage or is expected to be located in the 'next' message store.

Steps to Reproduce

Produce messages with message store pugin: TieredMessageStore open. Calling SEARCH_OFFSET_BY_TIMESTAMP API, compare result with cluster with defaultMessageStore.

What Did You Expect to See?

SEARCH_OFFSET_BY_TIMESTAMP should appear the same with two different storage plugin.

What Did You See Instead?

They appear different.

Additional Context

No response