Test suite `TestHnswMergeAbort` slows down build

[kaivalnp]

Description

#16368 recently added a new test suite TestHnswMergeAbort, which is slowing down local builds significantly:

The slowest tests during this run:
  53.24s TestHnswMergeAbort.testRollbackDuringFullRebuildMerge (:lucene:core)
  50.78s TestHnswMergeAbort.testRollbackDuringGraphJoinMerge (:lucene:core)
  50.19s TestHnswMergeAbort.testRollbackDuringConcurrentMerge (:lucene:core)
   6.23s TestRandomGeoShapeRelationship.testRandomOverlaps (:lucene:spatial3d)
   3.47s TestTermOrdValComparatorAdaptiveSkipping.testResultsCorrectForInterleavedData (:lucene:core)
   2.84s TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler (:lucene:core)
   2.71s TestTermOrdValComparatorAdaptiveSkipping.testResultsCorrectForRandomData (:lucene:core)
   2.62s TestSerializedIOCountingDirectory.testRandomShort (:lucene:test-framework)
   2.23s TestSimpleTextTermVectorsFormat.testMergeStability (:lucene:codecs)
   2.10s TestDuelingCodecs.testCrazyReaderEquals (:lucene:core)
The slowest suites during this run:
  154.22s TestHnswMergeAbort (:lucene:core)
  24.35s TestBasicBackwardsCompatibility (:lucene:backward-codecs)
  11.21s TestIndexUpgradeBackwardsCompatibility (:lucene:backward-codecs)
  10.52s TestBoolean2 (:lucene:core)
  10.52s TestTermOrdValComparatorAdaptiveSkipping (:lucene:core)
   8.86s TestSimpleExplanationsWithFillerDocs (:lucene:core)
   8.29s TestSimpleTextDocValuesFormat (:lucene:codecs)
   7.77s TestLucene90DocValuesFormat (:lucene:core)
   7.37s TestSimpleTextTermVectorsFormat (:lucene:codecs)
   7.21s TestIndexSortBackwardsCompatibility (:lucene:backward-codecs)

TestHnswMergeAbort is ~7x slower than the next slowest one.
I wonder if we can speed up the tests or mark them as @Monster?

Gradle command to reproduce

./gradlew check

[msokolov]

I see that test as docs-per-segment = 12_000; let's try reducing it to 1000? The test is also asserting on some time limitation, but this is likely not a reliable way to test that we are properly aborting. Maybe we can find a better way, but in the meantime, let's speed it up

[jeho-rpls]

Hi, I added this test in #16368.
The size was deliberate since the timing assertion needs a wide margin, but I did't weigh what that costs on every check run.

How about asserting through InfoStream that the graph build never ran to completion, instead of asserting on elapsed time?
I think that signal stays valid at any size, so docs per segment and beam width could be cut substantially.

If that sounds reasonable, I will open a PR and verify the smaller test still fails with the abort check removed.

[msokolov]

I ilke the InfoStream approach since we signal completion there. We can supply some kind of test-only MockInfoStream to the writer. Please feel free