…uery_config& cfg)`

This was buggy for non-monotonic `log`s.

From KIP-33 [1]:

"When searching by timestamp, broker will start from the earliest log segment
and check the last time index entry. If the timestamp of the last time index
entry is greater than the target timestamp, the broker will do binary search
on that time index to find the closest index entry and scan the log from there.
Otherwise it will move on to the next log segment."

Also,

"The time index is not monotonically increasing for the segments of a
partition. Instead, it is only monotonically increasing within each
individual time index file. i.e. It is possible that the time index file for
a later log segment contains smaller timestamp than some timestamp in the time
index file of an earlier segment."

Clearly, it is anticipated that `segment`s may not have monotonically increasing
reference timestamps in their time index (analogous to `redpanda`'s `segment_index`).
Ergo, the use of a binary search via `_seg.slower_bound(cfg.time)` is clearly
incorrect and can lead to some buggy behavior with timequeries.

This can be clearly demonstrated by a simple reproducer in which a Kafka client
produces to a `partition`, issues a timequery, waits for a `segment` roll, and
then issues another timequery without producing after the roll. Because
the `max_timestamp` of the `segment_index` defaults to `0`, the invalidation
of monotonicity leads to a different result for the timequery due to the use
of binary search.

This is particularly dangerous for a `DeleteRecords` request issued through
`rpk topic trim-prefix foo -o "@{timestamp}"`; using the above scenario, the
following behavior was observed:

```
$ rpk topic trim-prefix a -o "@1744708378681"
TOPIC  PARTITION  PRIOR-START-OFFSET  NEW-START-OFFSET
a      0          0                   3
a      1          0                   0
a      2          0                   0

? Confirm deletion of all data before the new start offsets? (Y/n)
```

(Wait for `segment` roll and repeat the same command)

```
$ rpk topic trim-prefix a -o "@1744708378681"
TOPIC  PARTITION  PRIOR-START-OFFSET  NEW-START-OFFSET
a      1          0                   9
a      2          0                   9
a      0          0                   9

? Confirm deletion of all data before the new start offsets? (Y/n)
```

Fix the issue by using a linear search in place of a binary search
in the `lock_manager::range_lock()` during a timequery.

[1]: https://cwiki.apache.org/confluence/display/KAFKA/KIP-33+-+Add+a+time+based+log+index

(cherry picked from commit 171c2a9)