Using a more aggressive closed timestamp target duration brings the
runtime for TestSQLWatcherReactsToUpdate down from 45s+ to single
digits. To speed it up, we also just re-use the same sqlwatcher instead
of creating a new one for every test case.

Other tests in the package benefit from a similar treatment. Using the
default target duration in fact masked a buggy test; in a future commit
we end up rewrite that test so it's skipped for now.

Release note: None

The only mutable state across concurrent WatchForSQLUpdate calls was the
internal buffer, which does not need to hang off the surrounding struct.
This obviates the need for the factory pattern we were using -- callers
can set up multiple SQLWatchers concurrently as is (see
TestSQLWatcherMultiple).

This commit simply hides the factory under the package boundary; in a
future commit we'll shed it altogether. This has the benefit of reducing
the number of symbols in pkg/spanconfig and making it symmetric with the
other spanconfig dependencies typically found together (KVAccessor,
SQLTranslator). It's also every-so-slightly less verbose to use in the
upcoming spanconfig.Reconciler (cockroachdb#71994).

Release note: None

A previous commit obviated the need for a factory altogether, but went
only as far hiding it within the package boundary. This commit gets rid
of it entirely.

Release note: None

If `system.{descriptor,zones}` is static, we would previously discard
all checkpoint events. This is not what we want -- we'd still like to
know how caught up we are, with ongoing updates or otherwise.

MVCC GC, after all, can still happen; if our last checkpoint was when
the last update occurred, we may end up doing a lot of unnecessary work
when finding out our last checkpoint was GC-ed from underneath us. Lack
of periodic checkpoints also makes tests difficult to write -- you'd
have to induce a benign update to flush out all earlier ones. This
latent flakiness was uncovered after speeding up some existing tests in
an earlier commit.

NB: For incremental (possibly noop) checkpoints, we need to ensure that
the sqlwatcher's buffer is initialized with a low watermark. When
flushing events, we take the most conservative timestamp. If not
initialized to a high water, this might be 0 -- violating the
sqlwatcher's monotonically increasing checkpoint ts invariant.

Release note: None