t4216-log-bloom.sh fails with -v (but not --verbose-log)

I haven't looked much into $subject, but there's an interesting regression in 2ca245f8be5 (csum-file.h: increase hashfile buffer size, 2021-05-18) where it fails with -v, but not --verbose-log. Discovered while running it manually.

This is a regression in v2.33.0 (not v2.34.0!), so nothing urgent, and this is pretty obscure anyway.

For the original change see: https://lore.kernel.org/git/64ffddd791160895b8e6730ebcddfac8458653f2.1621362768.git.gitgitgadget@gmail.com/

To reproduce it:

    make test T=t4216-log-bloom.sh GIT_TEST_OPTS=-v DEFAULT_TEST_TARGET=test

Removing the -v, or making it --verbose-log will make it succeed. It
fails on:
    
    + GIT_TEST_BLOOM_SETTINGS_MAX_CHANGED_PATHS=10 GIT_TRACE2_EVENT=/home/avar/g/git/t/trash directory.t4216-log-bloom/limits/trace git commit-graph write --reachable --changed-paths
    + test_max_changed_paths 10 trace
    + grep "max_changed_paths":10 trace
    error: last command exited with $?=1
    not ok 135 - correctly report changes over limit

If it's run with/without a debugging shimmy to save away the "trace" we can see that it doesn't include the max_changed_paths trace2 payload with -v. I.e. for some reason we either don't run trace2_bloom_filter_settings(), or don't log that data in the same way.

It's probably easy to figure out for someone familiar with this code, but I couldn't see it from some quick skimming. Hence this E-Mail.

FYI This is our only failure when running the whole test suite with -j1 -x (I didn't test a full run with just -v, takes a while, I was using -j1 to get sensible output at the end without needing to scroll up).