CASSANDRA-19569 Advance the offline SSTable rewrite cache advice position

[cheeeee]

CASSANDRA-19569 reports sstableupgrade running far below disk throughput, with a profile dominated by
posix_fadvise.

SSTableRewriter.maybeReopenEarly is called on every append and is meant to skip the page cache of the
source readers once per preemptiveOpenInterval bytes of output. The offline branch never updated
currentlyOpenedEarlyAt, so once the output exceeded the interval the condition held for every appended
partition, and each append performed an index lookup plus a POSIX_FADV_DONTNEED over [0, current
position) on every source file. The online branch already records the position when it reopens early.

Change: record writer.getFilePointer() after the offline cache skip, so the advice is issued once per
interval. One line, plus a corrected field comment (the value is a byte position, not MiB).

Testing:

• SSTableRewriterTest.testOfflineCacheSkippingAcrossWriterSwitches: Byteman on
  NativeLibrary.trySkipCache(String, long, long) records every advised range while an offline rewriter
  appends across three writers; asserts one advice per interval with the expected ranges. Without the fix
  it fails with an extra advice on the partition after the interval is first exceeded.
• Existing SSTableRewriterTest suite (22 tests) passes.
• Throughput on the same offline path (ext4, 50 MiB interval, JDK 11, median of three runs): 124 MB of
  ~1 KB partitions takes 6980 ms (17.0 MB/s) without the fix and 1894 ms (62.6 MB/s) with it; with
  ~84 B partitions, 5.8 MB/s against 18.0 MB/s, since the cost is per partition. bpftrace shows
  69,394 fadvise64 calls before against 3 after and 111,048 openat calls against 35,251, as
  trySkipCache(String, long, long) reopens the data file per call; only 253 ms of the difference is
  inside fadvise64. The ticket's ramdisk asymmetry did not reproduce: tmpfs is equally slow unpatched.

CASSANDRA-19569