preerase: Adopted PREERASE in tests, fixes, relaxed gbmap zeroing

Still needs testing with LFS3_GC=1, and tests that intentionally test
preerasing, but this should at least fix most fsinfo.flag related issues.

Despite no intentional preerase testing, this already found a number of
issues. Most importantly: our ckpoint-agnostic gbmap zeroing was never
going to work with preerasing!

Main fixes:

- Adopted conservative zeroing of gbmap during rebuilds

  This was the biggest change. Our previous lfs3_gbmap_zero impl was
  never going to work with preerasing because it unconditionally
  cleared BMERASED ranges.

  Not entirely wrong, but a big waste of any preerase work.

  It also causes the whole system to lock up when LFS3_GC_LOOKAHEAD and
  LFS3_GC_PREERASE fight to make progress. With LFS3_GC_LOOKAHEAD
  clearing BMERASED ranges, and LFS3_GC_PREERASE clearing the lookahead
  flag, nothing gets done!

  ---

  The fix was to rewrite lfs3_gbmap_zero[unknown] to only zero BMERASED
  (and BMINUSE, though this isn't strictly necessary) ranges in the
  unknown window. This keeps any known-preerased blocks around and
  avoids throwing that information away.

  This is also slightly different from BMBAD ranges, which we want to
  keep around forever, even if in the unknown window.

  Whether or not was should limit zeroing BMINUSE ranges is an
  interesting question. If we already need this logic, I think extending
  it to BMINUSE is a good idea because of how it limits gbmap commits
  during rebuilds:

  - Unfortunately, gbmap rebuilds require quite a few commits to both
    (1) zero gbmap state, and (2) set all the in-use blocks to BMINUSE.
    This is especially concerning when relying on aggressive gc, such as
    gc_lookgbmap=-1, which may trigger rebuilds when only a couple
    blocks are allocated.

    Limiting zeroing limits gbmap commits in two ways:

    1. We only need to update ranges in the unknown window, which
       shrinks with more aggressive gbmap rebuilds.

    2. By not clearing BMINUSE ranges in the known window, populating
       those blocks during the lookgbmap scan should be a noop.

    Together, this hopefully makes aggressive gbmap rebuilds relatively
    cheap, at least in terms of progs/erases.

  - It's slightly simpler if BMINUSE and BMERASED are handled the same.

- Actually increment the preeraser known window in lfs3_alloc_inc.

  Otherwise our estimated preeraser.count only ever increases! There was
  some trickiness to make sure preeraser.count is only ever decremented
  when allocating erased blocks, but fortunately lfs3->gbmap.ecksum's
  existence can tell us that information.

- Reset preeraser state during gbmap rebuilds.

  Also necessary to avoid unbounded preeraser.count. The simplest
  solution is to zero the preeraser, which forces it to rescan the gbmap
  for BMERASED ranges. The preeraser strictly avoids redundant erases.
  This does require extra gbmap lookups during LFS3_GC_PREERASE, but
  that's not the end of the world.

- Avoid erasing corrupted preerased blocks in case there's other
  preerased blocks available in our gbmap.

  This happens when the ecksum check fails, implying a prog was
  attempted, but power was lost.

  Before this change (the continue in lfs3_alloc_:11244), we were
  erasing corrupt ecksums, which is not _wrong_, but sort of defeats the
  purpose of prerasing. Skipping the block and trying another:

  1. Is better in terms of wear-leveling (try not to double erase!)
  2. Minimizes latency if we have other preerased blocks we can use

- Made lfs3_fs_gc_ preerasing actually conditional on the
  LFS3_GC_PREERASE flag.

  Before, lfs3_fs_gc_ was unconditionally preerasing, which is wrong!

---

Currently passing:

  LFS3_YES_GBMAP=1 \
          LFS3_YES_REVPERTURB=1 \
          LFS3_PREERASE=1 \
          make test-runner -j \
      & ./scripts/test.py -j -b

Other test fixes:

- Mostly just adding the necessary LFS3_I_PREERASE flags for all
  lfs3_fs_stat calls.

- LFS3_I_PREERASE and LFS3_I_LOOKAHEAD can interact in funny ways. Just
  needed testing.

- lfs3_trv_t doesn't actually do anything with LFS3_T_PREERASE, so we
  shouldn't try to test it.

- Adopted lfs3_fs_ck instead of explicit traversals where possible.

- test_badblocks_*_btree_many was still running with LFS3_YES_GBMAP, but
  it shouldn't be. The gbmap state is undefined during internal btree
  tests.

Code changes:

                    code          stack          ctx
  before:          35260           2136          660
  after:           35260 (+0.0%)   2136 (+0.0%)  660 (+0.0%)

                    code          stack          ctx
  gbmap before:    38492           2144          776
  gbmap after:     38560 (+0.2%)   2144 (+0.0%)  776 (+0.0%)

                    code          stack          ctx
  preerase before: 39036           2168          796
  preerase after:  39168 (+0.3%)   2168 (+0.0%)  796 (+0.0%)

tests/test_badblocks.toml

@@ -37,6 +37,8 @@ defines.LOOKAHEAD_SIZE = '(BLOCK_COUNT+8-1) / 8'
 defines.SEED = 42
 fuzz = 'SEED'
 if = 'LFS3_IFDEF_CKPROGS(true, !CKPROGS)'
+# don't bother testing with more complicated block allocators
+ifndef = 'LFS3_YES_GBMAP'
 in = 'lfs3.c'
 code = '''
     // test all possible bad blocks
@@ -1999,6 +2001,8 @@ defines.LOOKAHEAD_SIZE = '(BLOCK_COUNT+8-1) / 8'
 defines.SEED = 42
 fuzz = 'SEED'
 if = 'LFS3_IFDEF_CKPROGS(true, !CKPROGS)'
+# don't bother testing with more complicated block allocators
+ifndef = 'LFS3_YES_GBMAP'
 in = 'lfs3.c'
 code = '''
     // test a large region of bad blocks
@@ -3964,6 +3968,8 @@ defines.LOOKAHEAD_SIZE = '(BLOCK_COUNT+8-1) / 8'
 defines.SEED = 42
 fuzz = 'SEED'
 if = 'LFS3_IFDEF_CKPROGS(true, !CKPROGS)'
+# don't bother testing with more complicated block allocators
+ifndef = 'LFS3_YES_GBMAP'
 in = 'lfs3.c'
 code = '''
     // test a large region of bad blocks