Make empty CQ init faster in case of clean shutdown (backport #13856)

Make empty CQ init faster in case of clean shutdown

(cherry picked from commit d27d5c4)

This commit completes the backport of two upstream fixes for a startup
hang that caused a 1h46m maintenance window outage on a single-node
broker (b-fd0b2082, 2026-03-08).

Root cause: `maybe_deltas_to_betas/4` in `rabbit_variable_queue` enters
an effectively infinite recursive loop when recovering an empty classic
queue after a clean shutdown if `next_seq_id` is large. The loop
iterates once per historical seq_id entirely in memory (no disk I/O),
producing 100% CPU with near-zero EBS reads. The loop becomes truly
infinite once `DeltaSeqId` reaches `DeltaSeqIdEnd` because `d()` accepts
`start_seq_id = end_seq_id` with `count = 0`, and `read/3` returns `[]`
immediately, causing unconditional recursion.

PR rabbitmq#13856 (primary fix, `rabbit_classic_queue_index_v2`): When
`Segments = #{}` (no segment files) and `NextSeqIdHint` is available
from clean shutdown Terms, `bounds/2` now returns
`{NextSeqIdHint, NextSeqIdHint}` instead of `{0, 0}`, producing a blank
delta immediately so the loop never starts.

PR rabbitmq#15595 (safety net, `rabbit_variable_queue`): Adds a termination
guard `0 when DeltaSeqId1 >= DeltaSeqIdEnd` to `maybe_deltas_to_betas`
that returns `?BLANK_DELTA` instead of recursing when the end of the
range is reached with an empty result.

Conflict resolution for PR rabbitmq#13856: The upstream diff hardcodes
`rabbit_classic_queue_index_v2:bounds(IndexState, NextSeqIdHint)` because
v1 index support was removed in main before this fix was written. In
3.13.7, the call site uses `IndexMod:bounds(IndexState)` to dispatch
between `rabbit_queue_index` (v1) and `rabbit_classic_queue_index_v2`
(v2). The resolution preserves the `IndexMod` dispatch but routes to
`bounds/2` only when `IndexMod =:= rabbit_classic_queue_index_v2`, since
`rabbit_queue_index` has no `bounds/2` variant and the bug only affects
the v2 index path.

PR rabbitmq#15595 was not cherry-picked (it targets main where
`maybe_deltas_to_betas` has been renamed to `read_from_q_tail` and
`BLANK_DELTA` to `BLANK_Q_TAIL`). The fix was applied manually as a
single guard clause addition in 3.13.7 terminology.

The `variable_queue_restart_large_seq_id` test is commented out from the
`backing_queue_v1` suite. The fix is correct and complete for v2 queues
(the only version used in production, enforced by the AWS managed
operator policy). The v1 test fails because `rabbit_queue_index:bounds/1`
still returns `{0, 0}` for empty queues -- there is no upstream precedent
for patching it since v1 was removed from main before PR rabbitmq#13856 was
written.

…tibility fixes

This commit cherry-picks PR rabbitmq#13932 (bf8fd69, 'Add tests for
rabbit_classic_queue_index_v2:bounds/2') and applies the additional
changes required to make it correct in 3.13.7, where the v1 index
(`rabbit_queue_index`) still exists alongside the v2 index.

PR rabbitmq#13932 in upstream main:
- Removed the `bounds/1` shim from `rabbit_classic_queue_index_v2`
  (which had been added by PR rabbitmq#13856 as a compatibility wrapper)
- Updated test call sites in `backing_queue_SUITE` from
  `IndexMod:bounds(Qi)` to `IndexMod:bounds(Qi, Hint)`

Why the cherry-pick alone was insufficient for 3.13.7:

In upstream main, the v1<->v2 index conversion code in
`rabbit_variable_queue` and `rabbit_queue_index` had already been
removed by commit ecf4600 ('Remove availability of CQv1', March 2024)
before PR rabbitmq#13856 introduced `bounds/2` (May 2025). Therefore, when
PR rabbitmq#13932 removed the `bounds/1` shim, there were no production call
sites left that used the 1-argument form.

In 3.13.7, the v1<->v2 conversion code still exists. Two production
call sites were left calling the now-deleted `bounds/1`:
- `rabbit_variable_queue:convert_from_v2_to_v1` called
  `rabbit_classic_queue_index_v2:bounds(V2Index)`
- `rabbit_queue_index:recover_index_v2_common` called
  `rabbit_classic_queue_index_v2:bounds(V2State)`

Both crashed at runtime with `{undef, {rabbit_classic_queue_index_v2,
bounds, [...]}` when a queue version downgrade (v2->v1) was attempted,
as exercised by `classic_queue_prop_SUITE`.

Changes in this commit beyond the cherry-pick:

1. `rabbit_queue_index.erl`: Added `bounds/2` with the same
   `NextSeqIdHint` logic as PR rabbitmq#13856 applied to
   `rabbit_classic_queue_index_v2`. When `SegNums = []` (no segment
   files) and `NextSeqIdHint` is an integer, returns
   `{Hint, Hint, State}` instead of `{0, 0, State}`. The existing
   `bounds/1` is kept as a shim delegating to `bounds(State, undefined)`.
   Also updated the internal call to `rabbit_classic_queue_index_v2:bounds`
   in `recover_index_v2_common` to use `bounds/2`.

2. `rabbit_variable_queue.erl`: Updated the call in
   `convert_from_v2_to_v1` to `rabbit_classic_queue_index_v2:bounds/2`.
   Also simplified the `IndexMod:bounds` dispatch in `init/10` from a
   case expression (routing v2 to `bounds/2` and v1 to `bounds/1`) to a
   single `IndexMod:bounds(IndexState, NextSeqIdHint)` call, since both
   index modules now implement `bounds/2`.

3. `backing_queue_SUITE.erl`: Removed the comment block that had
   previously disabled `variable_queue_restart_large_seq_id` for the
   `backing_queue_v1` suite. With `rabbit_queue_index:bounds/2` now
   implemented, the fix is complete for both v1 and v2 queues and the
   test passes for both.

Validation: `backing_queue_SUITE` (all groups including `backing_queue_v1`
and `backing_queue_v2`) and `classic_queue_prop_SUITE` (6/6 tests) both
pass cleanly.

Make empty CQ init faster in case of clean shutdown

(cherry picked from commit d27d5c4)

This commit completes the backport of two upstream fixes for a startup
hang that caused a 1h46m maintenance window outage on a single-node
broker (b-fd0b2082, 2026-03-08).

Root cause: `maybe_deltas_to_betas/4` in `rabbit_variable_queue` enters
an effectively infinite recursive loop when recovering an empty classic
queue after a clean shutdown if `next_seq_id` is large. The loop
iterates once per historical seq_id entirely in memory (no disk I/O),
producing 100% CPU with near-zero EBS reads. The loop becomes truly
infinite once `DeltaSeqId` reaches `DeltaSeqIdEnd` because `d()` accepts
`start_seq_id = end_seq_id` with `count = 0`, and `read/3` returns `[]`
immediately, causing unconditional recursion.

PR rabbitmq#13856 (primary fix, `rabbit_classic_queue_index_v2`): When
`Segments = #{}` (no segment files) and `NextSeqIdHint` is available
from clean shutdown Terms, `bounds/2` now returns
`{NextSeqIdHint, NextSeqIdHint}` instead of `{0, 0}`, producing a blank
delta immediately so the loop never starts.

PR rabbitmq#15595 (safety net, `rabbit_variable_queue`): Adds a termination
guard `0 when DeltaSeqId1 >= DeltaSeqIdEnd` to `maybe_deltas_to_betas`
that returns `?BLANK_DELTA` instead of recursing when the end of the
range is reached with an empty result.

Conflict resolution for PR rabbitmq#13856: The upstream diff hardcodes
`rabbit_classic_queue_index_v2:bounds(IndexState, NextSeqIdHint)` because
v1 index support was removed in main before this fix was written. In
3.13.7, the call site uses `IndexMod:bounds(IndexState)` to dispatch
between `rabbit_queue_index` (v1) and `rabbit_classic_queue_index_v2`
(v2). The resolution preserves the `IndexMod` dispatch but routes to
`bounds/2` only when `IndexMod =:= rabbit_classic_queue_index_v2`, since
`rabbit_queue_index` has no `bounds/2` variant and the bug only affects
the v2 index path.

PR rabbitmq#15595 was not cherry-picked (it targets main where
`maybe_deltas_to_betas` has been renamed to `read_from_q_tail` and
`BLANK_DELTA` to `BLANK_Q_TAIL`). The fix was applied manually as a
single guard clause addition in 3.13.7 terminology.

The `variable_queue_restart_large_seq_id` test is commented out from the
`backing_queue_v1` suite. The fix is correct and complete for v2 queues
(the only version used in production, enforced by the AWS managed
operator policy). The v1 test fails because `rabbit_queue_index:bounds/1`
still returns `{0, 0}` for empty queues -- there is no upstream precedent
for patching it since v1 was removed from main before PR rabbitmq#13856 was
written.

…tibility fixes

This commit cherry-picks PR rabbitmq#13932 (bf8fd69, 'Add tests for
rabbit_classic_queue_index_v2:bounds/2') and applies the additional
changes required to make it correct in 3.13.7, where the v1 index
(`rabbit_queue_index`) still exists alongside the v2 index.

PR rabbitmq#13932 in upstream main:
- Removed the `bounds/1` shim from `rabbit_classic_queue_index_v2`
  (which had been added by PR rabbitmq#13856 as a compatibility wrapper)
- Updated test call sites in `backing_queue_SUITE` from
  `IndexMod:bounds(Qi)` to `IndexMod:bounds(Qi, Hint)`

Why the cherry-pick alone was insufficient for 3.13.7:

In upstream main, the v1<->v2 index conversion code in
`rabbit_variable_queue` and `rabbit_queue_index` had already been
removed by commit ecf4600 ('Remove availability of CQv1', March 2024)
before PR rabbitmq#13856 introduced `bounds/2` (May 2025). Therefore, when
PR rabbitmq#13932 removed the `bounds/1` shim, there were no production call
sites left that used the 1-argument form.

In 3.13.7, the v1<->v2 conversion code still exists. Two production
call sites were left calling the now-deleted `bounds/1`:
- `rabbit_variable_queue:convert_from_v2_to_v1` called
  `rabbit_classic_queue_index_v2:bounds(V2Index)`
- `rabbit_queue_index:recover_index_v2_common` called
  `rabbit_classic_queue_index_v2:bounds(V2State)`

Both crashed at runtime with `{undef, {rabbit_classic_queue_index_v2,
bounds, [...]}` when a queue version downgrade (v2->v1) was attempted,
as exercised by `classic_queue_prop_SUITE`.

Changes in this commit beyond the cherry-pick:

1. `rabbit_queue_index.erl`: Added `bounds/2` with the same
   `NextSeqIdHint` logic as PR rabbitmq#13856 applied to
   `rabbit_classic_queue_index_v2`. When `SegNums = []` (no segment
   files) and `NextSeqIdHint` is an integer, returns
   `{Hint, Hint, State}` instead of `{0, 0, State}`. The existing
   `bounds/1` is kept as a shim delegating to `bounds(State, undefined)`.
   Also updated the internal call to `rabbit_classic_queue_index_v2:bounds`
   in `recover_index_v2_common` to use `bounds/2`.

2. `rabbit_variable_queue.erl`: Updated the call in
   `convert_from_v2_to_v1` to `rabbit_classic_queue_index_v2:bounds/2`.
   Also simplified the `IndexMod:bounds` dispatch in `init/10` from a
   case expression (routing v2 to `bounds/2` and v1 to `bounds/1`) to a
   single `IndexMod:bounds(IndexState, NextSeqIdHint)` call, since both
   index modules now implement `bounds/2`.

3. `backing_queue_SUITE.erl`: Removed the comment block that had
   previously disabled `variable_queue_restart_large_seq_id` for the
   `backing_queue_v1` suite. With `rabbit_queue_index:bounds/2` now
   implemented, the fix is complete for both v1 and v2 queues and the
   test passes for both.

Validation: `backing_queue_SUITE` (all groups including `backing_queue_v1`
and `backing_queue_v2`) and `classic_queue_prop_SUITE` (6/6 tests) both
pass cleanly.