[Why]

This flaked today since the restart too 309ms, why above
the allowed 100ms (outside of CI, it takes single-digit ms)

[How]
Increase the allowed time but also significantly increase next_seq_id.
This test exists because in the past we had an O(n) algorithm in CQ
recovery, leading to a slow recovery of even empty queues, if they had
a very large next_seq_id. Now that this operation is O(1), a much larger
next_seq_id shouldn't affect the time it takes to run
this test, while accidentally re-intrudcing an O(n) algorithm should
fail this test consistently.

Author: mkuratczyk

deps/rabbit/test/backing_queue_SUITE.erl

@@ -1447,7 +1447,7 @@ variable_queue_restart_large_seq_id2(VQ0, QName) ->
 
     %% set a very high next_seq_id as if 100M messages have been
     %% published and consumed
-    Terms2 = lists:keyreplace(next_seq_id, 1, Terms, {next_seq_id, 100_000_000}),
+    Terms2 = lists:keyreplace(next_seq_id, 1, Terms, {next_seq_id, 100_000_000_000}),
 
     {TInit, VQ3} =
         timer:tc(
@@ -1456,7 +1456,7 @@ variable_queue_restart_large_seq_id2(VQ0, QName) ->
     %% even with a very high next_seq_id start of an empty queue
     %% should be quick (few milliseconds, but let's give it 100ms, to
     %% avoid flaking on slow servers)
-    {true, _} = {TInit < 100, TInit},
+    {true, _} = {TInit < 500, TInit},
 
     %% should be empty now
     true = rabbit_variable_queue:is_empty(VQ3),