Store backfill_processes status for protection against interruptions

[bitwiseguy]

Description

There is currently a failure mode where if the blob-archiver gets restarted before a backfill process completes, there is a gap in blob slots stored that will go undetected unless there is an external tool (i.e. blob-validator) running to catch the missing slots.

This PR introduces a backfill_processes file/object that is stored in persistent memory (either s3 or a file). That object contains information about any ongoing backfill processes so that they will be resumed during the blob-archiver startup routine. This reduces the dependence on external tools.

This change is meant to be backward compatible with existing blob-archivers.

Additional context

Changes made:

• added new storage.WriteBackfillProcesses method
• added new storage.ReadBackfillProcesses method
• renamed storage.Write --> storage.WriteBlobs to distinguish from the new storage.WriteBackfillProcesses
• renamed storage.Read --> storage.ReadBlobs to distinguish from the new storage.ReadBackfillProcesses
• added archiver test: TestArchiver_BackfillFinishOldProcess
• during storage initialization, if a backfill_processes file/object does not exist, it will create an empty one
• updated archiver.backfillBlobs method to utilize the new storage methods and loop through all new and old backfill processes, completing them one-by-one. When all processes are completed, the content in the backfill_processes file in storage should just be an empty mapping

Open questions

• Should the new backfill_processes functionality be hidden behind a feature flag and remain off-by-default?
• Does it matter that the order in which backfill_processes are completed is not based on the slot number (i.e. the highest or lowest slot number is not what determines which process is done first)? Rather, the hash of the block header and its order in a mapping is what determines the order of processing.