Catchpoint Retention Policy

## Status

Today, the catchpoint policy has the following configurations:
* "CatchpointFileHistoryLength": 365,
* "CatchpointInterval": 10000,
* "CatchpointTracking": 0,

After `CatchpointFileHistoryLength * CatchpointInterval` rounds, you are unable to use fast catchup. This equates to approximately 6 months into the past.

## Expected

We should have an improved retention policy which allows for sparse catchpoints over a longer period of time. Preferably going back to round 0.

## Solution

Additional configurations to control the sparseness of catchpoints for a longer duration.

New configurations:

* "CatchpointMinInterval": 500000, - after the FileHistoryLength, a catchpoint with this interval will always be maintained. MUST BE A FACTOR OF `CaatchpointInterval`.
* "CatchpointSparsity": 50 - every `CatchpointSparsity` catchpoints, the sparsity of catchpoints increases by a factor of two.

For example, with the following configuration:
* "CatchpointFileHistoryLength": 365,
* "CatchpointInterval": 10000,
* "CatchpointTracking": 0,
* "CatchpointMinInterval": 500000,
* "CatchpointSparsity": 50,

The following catchpoints would be kept:
* 1-50: Catchpoint every `CatchpointInterval` rounds (10k / ~12h)
* 51-100: `2 * CatchpointInteval` (20k / 24h)
* 101-150: `4 * CatchpointInteval` (40k / 2d)
* 151-200: `8 * CatchpointInteval` (80k / 4d)
* 201-250: `16 * CatchpointInteval` (160k / 8d)
* 251-300: `32 * CatchpointInteval` (320k / 16d)
* 301-350: `64 * CatchpointInteval` (500k / 32d -- `CatchpointMinInterval` is reached)
* 351-400: `128 * CatchpointInteval` (500k / 32d -- `CatchpointMinInterval` is reached)

*Note:* in this example `CatchpoiontFileHistoryLength` is not used. With a larger `CatchpointSparsity`, or a smaller `CatchpointFileHistoryLength` there would be some additional pruning between the largest sparceness factor, and the `CatchpointMinInterval`.

## Dependencies

Hyperflow - requires updates to the catchpoint label txt file.

Considerations for how to deploy this configuration need to be made. Specifically, in order to fill in the older catchpoints a node rebuild is required.

## Urgency

This feature would be incredibly useful for internal development. We frequently make note of "interesting" rounds for testing purposes (i.e. a round that includes a state proof, a round that includes a KVMod, a round that includes an unusual number of transactions, a round that includes an unusual series of app calls). As the catchpoints expire it becomes unfeasible to test against these rounds due to the time cost to setup a node that would reach it.