[weim0000]

Description

The RocksDB checkpoint used to feed replicas during full synchronization was
purged with two hard-coded thresholds in Storage::TryPurgeCheckpoint:

• purge when no replica is fetching files and the checkpoint has been idle for
  more than 30 seconds;
• purge when the checkpoint has existed for more than 24 hours, even if replicas
  are still fetching its files.

Both values were fixed constants, which cannot be tuned per deployment: a slow or
far-away replica may legitimately need to fetch checkpoint files for longer than
the idle window, while an operator on a disk-constrained node may want to reclaim
the checkpoint (and the SST files it keeps alive) much earlier than 24 hours.

This change turns those thresholds into two runtime-configurable options while
keeping the current values as the defaults, so the existing behavior is unchanged
for everyone who does not set them:

Option	Default	Meaning
checkpoint-alive-time-secs	86400 (24h)	Max lifetime of a full-sync checkpoint; purge even with active fetchers once exceeded.
checkpoint-idle-time-secs	30	Idle time before purging an unused checkpoint (no replica fetching).

This removes the long-standing TODO(shooterit): support to config the alive time of checkpoint, originally introduced when the checkpoint-based full replication
was added (#205).

Changes

• Add checkpoint_alive_time_secs and checkpoint_idle_time_secs to Config
  and register them as IntFields (range [1, INT_MAX]) so they can be set via
  kvrocks.conf, CONFIG SET/GET and survive CONFIG REWRITE.
• Use the config values in Storage::TryPurgeCheckpoint instead of the hard-coded
  30 and 24 * 60 * 60, and drop the TODO comment.
• Add a SetCheckpointCreateTimeSecs accessor (symmetric with the existing access
  time setter) to make the purge policy directly testable.
• Document both options in kvrocks.conf next to purge-backup-on-fullsync.

Note: the shared-checkpoint reuse window in GetFullReplDataInfo (derived from
rocksdb.wal-ttl-seconds) is a separate concern about whether a replica may reuse
an existing checkpoint, not about when the checkpoint is purged; it is left
untouched here.

Side effects / Compatibility

No storage-format, replication-protocol or column-family changes. The new options
are backward compatible: when unset, the behavior is byte-for-byte identical to the
previous hard-coded 30s / 24h policy.

AI Usage Disclosure

• AI tools(Qoder) were used to assist in generating the code; and all code was reviewed and verified by the author.