### What problem does this PR solve?

Issue Number: None

Related PR: #67228

Problem Summary:

PR #67228 added `LookupConnectionCacheBlockPoolSize` with `TEST` to the
existing `ConfigValidatorTest` suite, while the suite already uses
`TEST_F`. GoogleTest requires all tests in a suite to use the same
fixture declaration and fails during test registration:

```text
All tests in the same test suite must use the same test fixture
```

Change the new case to `TEST_F` so it uses the existing fixture
consistently.

### Release note

None

### Check List (For Author)

- Test: No need to test (one-line GoogleTest fixture declaration
correction)
- Behavior changed: No
- Does this need documentation: No

…69020)

#67228

Co-authored-by: TRAE CLI <[email protected]>

### What problem does this PR solve?

Issue Number: None

Related PR: apache#67180, apache#67228

Problem Summary:

jni_scanner_heap_budget_ratio and jni_scanner_heap_max_wait_ms can be changed on a running BE.
config::set_config() assigns the plain global under mutable_string_config_lock, while JniScanHeapGate
read both without it: the ratio in jvm_heap_budget(), which the scan workers and the gate's own thread
call whenever they decide an admission, and the wait limit in _poll(), on the gate's thread. That is a
data race by the letter of the standard, which a TSAN build reports. On 64-bit targets the read only
ever sees the old or the new value, and the gate takes either: the account moves only by each
admission's own bytes and the wait limit is compared with each waiter's own start, so nothing could
underflow or be left behind.

The earlier reply to the review kept the plain reads, saying atomic storage would make these the only
atomic mutable configs in BE. That was wrong: inverted_index_candidate_pushdown_ratio, an mDouble read
on the scan path, has been read from an atomic copy since apache#67180, whose author confirmed the same race,
and apache#67228 does the same for lookup_connection_cache_block_pool_size. The gate's two settings now follow
them: an atomic copy each, published by init() once be.conf is read and by an update callback on every
set_config(), read through config::get_jni_scanner_heap_budget_ratio() and
config::get_jni_scanner_heap_max_wait_ms(); relaxed, since neither publishes anything else. The tests
that set the two configs by assignment now go through set_config(), which is what publishes the copies;
the ratio that gives the process gate 10 MB is written with fmt's shortest round-trip text, so it parses
back to the same double.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - No new case: the existing cases already read the published copies. JniScanHeapGateTest's two
      wait-limit cases set the limit to 200 and 300 ms, and JniTableReaderTest's process gate sets the
      ratio, both now through set_config(); had it not published, the waiters would wait out 60 s and
      the process gate would keep half of an unlimited heap, and those cases would fail. The changed
      sources, JniScanHeapGateTest, ScannerContextTest and JniTableReaderTest compile (-fsyntax-only)
      with the BE UT flags (ASAN), as does the unity batch that holds the gate; clang-format 16 and the
      build hygiene gates pass. Not run locally: config.h changed, so the UT target in this worktree
      would rebuild nearly all of BE; left to CI
- Behavior changed: No
- Does this need documentation: No

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

### What problem does this PR solve?

Issue Number: None

Related PR: apache#67180, apache#67228

Problem Summary:

jni_scanner_heap_budget_ratio and jni_scanner_heap_max_wait_ms can be changed on a running BE.
config::set_config() assigns the plain global under mutable_string_config_lock, while JniScanHeapGate
read both without it: the ratio in jvm_heap_budget(), which the scan workers and the gate's own thread
call whenever they decide an admission, and the wait limit in _poll(), on the gate's thread. That is a
data race by the letter of the standard, which a TSAN build reports. On 64-bit targets the read only
ever sees the old or the new value, and the gate takes either: the account moves only by each
admission's own bytes and the wait limit is compared with each waiter's own start, so nothing could
underflow or be left behind.

The earlier reply to the review kept the plain reads, saying atomic storage would make these the only
atomic mutable configs in BE. That was wrong: inverted_index_candidate_pushdown_ratio, an mDouble read
on the scan path, has been read from an atomic copy since apache#67180, whose author confirmed the same race,
and apache#67228 does the same for lookup_connection_cache_block_pool_size. The gate's two settings now follow
them: an atomic copy each, published by init() once be.conf is read and by an update callback on every
set_config(), read through config::get_jni_scanner_heap_budget_ratio() and
config::get_jni_scanner_heap_max_wait_ms(); relaxed, since neither publishes anything else. The tests
that set the two configs by assignment now go through set_config(), which is what publishes the copies;
the ratio that gives the process gate 10 MB is written with fmt's shortest round-trip text, so it parses
back to the same double.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - No new case: the existing cases already read the published copies. JniScanHeapGateTest's two
      wait-limit cases set the limit to 200 and 300 ms, and JniTableReaderTest's process gate sets the
      ratio, both now through set_config(); had it not published, the waiters would wait out 60 s and
      the process gate would keep half of an unlimited heap, and those cases would fail. The changed
      sources, JniScanHeapGateTest, ScannerContextTest and JniTableReaderTest compile (-fsyntax-only)
      with the BE UT flags (ASAN), as does the unity batch that holds the gate; clang-format 16 and the
      build hygiene gates pass. Not run locally: config.h changed, so the UT target in this worktree
      would rebuild nearly all of BE; left to CI
- Behavior changed: No
- Does this need documentation: No

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

### What problem does this PR solve?

Issue Number: None

Related PR: apache#67180, apache#67228

Problem Summary:

jni_scanner_heap_budget_ratio and jni_scanner_heap_max_wait_ms can be changed on a running BE.
config::set_config() assigns the plain global under mutable_string_config_lock, while JniScanHeapGate
read both without it: the ratio in jvm_heap_budget(), which the scan workers and the gate's own thread
call whenever they decide an admission, and the wait limit in _poll(), on the gate's thread. That is a
data race by the letter of the standard, which a TSAN build reports. On 64-bit targets the read only
ever sees the old or the new value, and the gate takes either: the account moves only by each
admission's own bytes and the wait limit is compared with each waiter's own start, so nothing could
underflow or be left behind.

The earlier reply to the review kept the plain reads, saying atomic storage would make these the only
atomic mutable configs in BE. That was wrong: inverted_index_candidate_pushdown_ratio, an mDouble read
on the scan path, has been read from an atomic copy since apache#67180, whose author confirmed the same race,
and apache#67228 does the same for lookup_connection_cache_block_pool_size. The gate's two settings now follow
them: an atomic copy each, published by init() once be.conf is read and by an update callback on every
set_config(), read through config::get_jni_scanner_heap_budget_ratio() and
config::get_jni_scanner_heap_max_wait_ms(); relaxed, since neither publishes anything else. The tests
that set the two configs by assignment now go through set_config(), which is what publishes the copies;
the ratio that gives the process gate 10 MB is written with fmt's shortest round-trip text, so it parses
back to the same double.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - No new case: the existing cases already read the published copies. JniScanHeapGateTest's two
      wait-limit cases set the limit to 200 and 300 ms, and JniTableReaderTest's process gate sets the
      ratio, both now through set_config(); had it not published, the waiters would wait out 60 s and
      the process gate would keep half of an unlimited heap, and those cases would fail. The changed
      sources, JniScanHeapGateTest, ScannerContextTest and JniTableReaderTest compile (-fsyntax-only)
      with the BE UT flags (ASAN), as does the unity batch that holds the gate; clang-format 16 and the
      build hygiene gates pass. Not run locally: config.h changed, so the UT target in this worktree
      would rebuild nearly all of BE; left to CI
- Behavior changed: No
- Does this need documentation: No

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

### What problem does this PR solve?

Issue Number: None

Related PR: apache#67180, apache#67228

Problem Summary:

jni_scanner_heap_budget_ratio and jni_scanner_heap_max_wait_ms can be changed on a running BE.
config::set_config() assigns the plain global under mutable_string_config_lock, while JniScanHeapGate
read both without it: the ratio in jvm_heap_budget(), which the scan workers and the gate's own thread
call whenever they decide an admission, and the wait limit in _poll(), on the gate's thread. That is a
data race by the letter of the standard, which a TSAN build reports. On 64-bit targets the read only
ever sees the old or the new value, and the gate takes either: the account moves only by each
admission's own bytes and the wait limit is compared with each waiter's own start, so nothing could
underflow or be left behind.

The earlier reply to the review kept the plain reads, saying atomic storage would make these the only
atomic mutable configs in BE. That was wrong: inverted_index_candidate_pushdown_ratio, an mDouble read
on the scan path, has been read from an atomic copy since apache#67180, whose author confirmed the same race,
and apache#67228 does the same for lookup_connection_cache_block_pool_size. The gate's two settings now follow
them: an atomic copy each, published by init() once be.conf is read and by an update callback on every
set_config(), read through config::get_jni_scanner_heap_budget_ratio() and
config::get_jni_scanner_heap_max_wait_ms(); relaxed, since neither publishes anything else. The tests
that set the two configs by assignment now go through set_config(), which is what publishes the copies;
the ratio that gives the process gate 10 MB is written with fmt's shortest round-trip text, so it parses
back to the same double.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - No new case: the existing cases already read the published copies. JniScanHeapGateTest's two
      wait-limit cases set the limit to 200 and 300 ms, and JniTableReaderTest's process gate sets the
      ratio, both now through set_config(); had it not published, the waiters would wait out 60 s and
      the process gate would keep half of an unlimited heap, and those cases would fail. The changed
      sources, JniScanHeapGateTest, ScannerContextTest and JniTableReaderTest compile (-fsyntax-only)
      with the BE UT flags (ASAN), as does the unity batch that holds the gate; clang-format 16 and the
      build hygiene gates pass. Not run locally: config.h changed, so the UT target in this worktree
      would rebuild nearly all of BE; left to CI
- Behavior changed: No
- Does this need documentation: No

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

### What problem does this PR solve?

Issue Number: None

Related PR: apache#67180, apache#67228

Problem Summary:

jni_scanner_heap_budget_ratio and jni_scanner_heap_max_wait_ms can be changed on a running BE.
config::set_config() assigns the plain global under mutable_string_config_lock, while JniScanHeapGate
read both without it: the ratio in jvm_heap_budget(), which the scan workers and the gate's own thread
call whenever they decide an admission, and the wait limit in _poll(), on the gate's thread. That is a
data race by the letter of the standard, which a TSAN build reports. On 64-bit targets the read only
ever sees the old or the new value, and the gate takes either: the account moves only by each
admission's own bytes and the wait limit is compared with each waiter's own start, so nothing could
underflow or be left behind.

The earlier reply to the review kept the plain reads, saying atomic storage would make these the only
atomic mutable configs in BE. That was wrong: inverted_index_candidate_pushdown_ratio, an mDouble read
on the scan path, has been read from an atomic copy since apache#67180, whose author confirmed the same race,
and apache#67228 does the same for lookup_connection_cache_block_pool_size. The gate's two settings now follow
them: an atomic copy each, published by init() once be.conf is read and by an update callback on every
set_config(), read through config::get_jni_scanner_heap_budget_ratio() and
config::get_jni_scanner_heap_max_wait_ms(); relaxed, since neither publishes anything else. The tests
that set the two configs by assignment now go through set_config(), which is what publishes the copies;
the ratio that gives the process gate 10 MB is written with fmt's shortest round-trip text, so it parses
back to the same double.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - No new case: the existing cases already read the published copies. JniScanHeapGateTest's two
      wait-limit cases set the limit to 200 and 300 ms, and JniTableReaderTest's process gate sets the
      ratio, both now through set_config(); had it not published, the waiters would wait out 60 s and
      the process gate would keep half of an unlimited heap, and those cases would fail. The changed
      sources, JniScanHeapGateTest, ScannerContextTest and JniTableReaderTest compile (-fsyntax-only)
      with the BE UT flags (ASAN), as does the unity batch that holds the gate; clang-format 16 and the
      build hygiene gates pass. Not run locally: config.h changed, so the UT target in this worktree
      would rebuild nearly all of BE; left to CI
- Behavior changed: No
- Does this need documentation: No

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

### What problem does this PR solve?

Issue Number: None

Related PR: apache#67180, apache#67228

Problem Summary:

jni_scanner_heap_budget_ratio and jni_scanner_heap_max_wait_ms can be changed on a running BE, and
neither had a validator. config::strtox takes whatever strtod or strtoll parses, so set_config() and
be.conf accepted nan, inf, -1 or 2 for the ratio and any int64 for the wait, and the gate computed
with them as given:

- jvm_heap_budget() multiplies the JVM's maximum heap by the ratio and converts the product to int64.
  A NaN ratio fails the comparison that keeps an unlimited heap unlimited and reaches
  static_cast<int64_t>(NaN), which is undefined behavior. An infinite ratio makes the budget
  unlimited and admits every reader, one above 1 lets the declarations add up to more than the heap,
  and a negative one is no share at all.
- _poll() takes the wait limit in nanoseconds as ms * 1000 * 1000. A negative wait admits every
  waiting reader at the gate's next poll, at most 100 ms later, and one above INT64_MAX / 10^6 ms
  overflows the multiplication, undefined behavior again.

The atomic copies the gate reads the two values from ("Read the JNI heap gate's two BE configs from
atomic copies", earlier in this PR) make publishing them free of races; they do not make the values
usable. The two configs that commit followed, inverted_index_candidate_pushdown_ratio and
lookup_connection_cache_block_pool_size, also have a DEFINE_Validator, and now so do these: the
ratio takes a finite number from 0 to 1 (at 0 the declaring readers open one at a time, unless they
wait out the limit), the wait 0 to INT64_MAX / 10^6 ms, the most _poll() can count in nanoseconds.
set_config() runs a validator before it persists the value or calls the update callback, so a
refused value puts the old one back and never reaches the copy the gate reads; a refused value in
be.conf fails config::init(), as for every other validated config.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - JniScanHeapGateTest.SettingsTheGateCannotUseAreRefused: both ends of each range are taken (the
      ratio 0 and 1, the wait 0 and 9223372036854 ms), which shows the field names are right and
      only the validators refuse; then nan, inf, -0.1 and 1.5 for the ratio and -1 and
      9223372036855 ms for the wait are refused, and the gate still reads the last values taken.
      Without the validators set_config() takes every one of the refused values (read from
      UPDATE_FIELD), so the case would fail. The fixture now also puts the ratio back after each case.
    - config.cpp and the test compile (-fsyntax-only) with the BE UT flags (ASAN, -Werror); clang-tidy
      reports nothing on the changed lines; clang-format 16 and the build hygiene gates pass. Not run
      locally: this worktree has no BE UT build, and one would compile all of BE; left to CI
- Behavior changed: Yes. set_config() and be.conf refuse a value of the two configs outside the
  ranges above. Both configs are new in this PR, and every value the gate could use is still taken
- Does this need documentation: No. The ranges go into the doc of the two configs, which is to follow

Co-Authored-By: Claude Opus 5.5 <[email protected]>

### What problem does this PR solve?

Issue Number: None

Related PR: apache#67180, apache#67228

Problem Summary:

jni_scanner_heap_budget_ratio and jni_scanner_heap_max_wait_ms can be changed on a running BE.
config::set_config() assigns the plain global under mutable_string_config_lock, while JniScanHeapGate
read both without it: the ratio in jvm_heap_budget(), which the scan workers and the gate's own thread
call whenever they decide an admission, and the wait limit in _poll(), on the gate's thread. That is a
data race by the letter of the standard, which a TSAN build reports. On 64-bit targets the read only
ever sees the old or the new value, and the gate takes either: the account moves only by each
admission's own bytes and the wait limit is compared with each waiter's own start, so nothing could
underflow or be left behind.

The earlier reply to the review kept the plain reads, saying atomic storage would make these the only
atomic mutable configs in BE. That was wrong: inverted_index_candidate_pushdown_ratio, an mDouble read
on the scan path, has been read from an atomic copy since apache#67180, whose author confirmed the same race,
and apache#67228 does the same for lookup_connection_cache_block_pool_size. The gate's two settings now follow
them: an atomic copy each, published by init() once be.conf is read and by an update callback on every
set_config(), read through config::get_jni_scanner_heap_budget_ratio() and
config::get_jni_scanner_heap_max_wait_ms(); relaxed, since neither publishes anything else. The tests
that set the two configs by assignment now go through set_config(), which is what publishes the copies;
the ratio that gives the process gate 10 MB is written with fmt's shortest round-trip text, so it parses
back to the same double.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - No new case: the existing cases already read the published copies. JniScanHeapGateTest's two
      wait-limit cases set the limit to 200 and 300 ms, and JniTableReaderTest's process gate sets the
      ratio, both now through set_config(); had it not published, the waiters would wait out 60 s and
      the process gate would keep half of an unlimited heap, and those cases would fail. The changed
      sources, JniScanHeapGateTest, ScannerContextTest and JniTableReaderTest compile (-fsyntax-only)
      with the BE UT flags (ASAN), as does the unity batch that holds the gate; clang-format 16 and the
      build hygiene gates pass. Not run locally: config.h changed, so the UT target in this worktree
      would rebuild nearly all of BE; left to CI
- Behavior changed: No
- Does this need documentation: No

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

### What problem does this PR solve?

Issue Number: None

Related PR: apache#67180, apache#67228

Problem Summary:

jni_scanner_heap_budget_ratio and jni_scanner_heap_max_wait_ms can be changed on a running BE, and
neither had a validator. config::strtox takes whatever strtod or strtoll parses, so set_config() and
be.conf accepted nan, inf, -1 or 2 for the ratio and any int64 for the wait, and the gate computed
with them as given:

- jvm_heap_budget() multiplies the JVM's maximum heap by the ratio and converts the product to int64.
  A NaN ratio fails the comparison that keeps an unlimited heap unlimited and reaches
  static_cast<int64_t>(NaN), which is undefined behavior. An infinite ratio makes the budget
  unlimited and admits every reader, one above 1 lets the declarations add up to more than the heap,
  and a negative one is no share at all.
- _poll() takes the wait limit in nanoseconds as ms * 1000 * 1000. A negative wait admits every
  waiting reader at the gate's next poll, at most 100 ms later, and one above INT64_MAX / 10^6 ms
  overflows the multiplication, undefined behavior again.

The atomic copies the gate reads the two values from ("Read the JNI heap gate's two BE configs from
atomic copies", earlier in this PR) make publishing them free of races; they do not make the values
usable. The two configs that commit followed, inverted_index_candidate_pushdown_ratio and
lookup_connection_cache_block_pool_size, also have a DEFINE_Validator, and now so do these: the
ratio takes a finite number from 0 to 1 (at 0 the declaring readers open one at a time, unless they
wait out the limit), the wait 0 to INT64_MAX / 10^6 ms, the most _poll() can count in nanoseconds.
set_config() runs a validator before it persists the value or calls the update callback, so a
refused value puts the old one back and never reaches the copy the gate reads; a refused value in
be.conf fails config::init(), as for every other validated config.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - JniScanHeapGateTest.SettingsTheGateCannotUseAreRefused: both ends of each range are taken (the
      ratio 0 and 1, the wait 0 and 9223372036854 ms), which shows the field names are right and
      only the validators refuse; then nan, inf, -0.1 and 1.5 for the ratio and -1 and
      9223372036855 ms for the wait are refused, and the gate still reads the last values taken.
      Without the validators set_config() takes every one of the refused values (read from
      UPDATE_FIELD), so the case would fail. The fixture now also puts the ratio back after each case.
    - config.cpp and the test compile (-fsyntax-only) with the BE UT flags (ASAN, -Werror); clang-tidy
      reports nothing on the changed lines; clang-format 16 and the build hygiene gates pass. Not run
      locally: this worktree has no BE UT build, and one would compile all of BE; left to CI
- Behavior changed: Yes. set_config() and be.conf refuse a value of the two configs outside the
  ranges above. Both configs are new in this PR, and every value the gate could use is still taken
- Does this need documentation: No. The ranges go into the doc of the two configs, which is to follow

Co-Authored-By: Claude Opus 5.5 <[email protected]>