MDEV-39538: Different costs when same range is read twice

[bsrikanth-mariadb]

When same range is used as a filter, once in the outer query block, and the second inside a sub query such as: -

select * from t1
where year(a) = 2010 and c < (select count(*) from t1 where year(a) = 2010);

The Optimizer Context had two records for multi_range_read_info_const() call, but had different cost vector members.
The cause is that the first table considered index-only scan on the range, while the second considered non-index only scan.

However, when replaying the context, the same range got matched twice, and the costs corresponding to that got returned twice. Hence the costs in the explain plan output differed as well.

Solution

Include a new field called "call_number", while recording range contexts into the overall context. This way, we could even match the call_number and return the appropriate cost during replay.

[gemini-code-assist]

Code Review

This pull request introduces a tracking mechanism for multi-range read (MRR) calls using a counter (call_number) to resolve issues where different costs are calculated when the same range is read multiple times. Feedback on the changes highlights a critical null-pointer dereference risk in sql/opt_context_store_replay.cc where call_number is assigned before verifying if range_ctx is null. Additionally, an optimization is suggested to defer sequence iterator initialization until after verifying the call_number matches the current counter.