Automated Watermark based LRU garbage collection and Transient Quota allocation

[aarshkshah1992]

This PR introduces automated watermark based LRU GC of transients along with a quota reservation mechanism to allow for downloading transients whose size we do not know upfront.

• The dagstore now performs automated high->low watermark based GC for transient files.

• Users who want to use this feature will have to configure a maximum size for the transients directory and the dagstore guarantees that the size of the transients directory will never exceed that limit.

• Users will also have to configure a high and low watermark for the transients directory. The dagstore will kickstart an automated GC when it detects that the size of the transients directory has crossed the high watermark and will attempt to bring down the directory size below the low watermark threshold.

• Users will have to configure a GC Strategy that will recommend the order in which reclaimable shards should be GC'd by the automated GC mechanism. The dagstore comes inbuilt with an LRU GC Strategy but users are free to implement their own. See the documentation of GarbageCollectionStrategy for more details.

• A quota reservation mechanism has been introduced for downloading transients whose size we do not know upfront. To download such a CAR, the downloader will first get a reservation from the dagstore for a preconfigured number of bytes, then download those many bytes and then go back to the allocator for more reservation if it hasn't finished downloading the transient. In the end, it will release unused reserved bytes back to the allocator.

• The existing manual GC mechanism works as is and no changes have been made to it.

Known Edge Case

There is an unhandled known edge case in the code.

If a group of concurrent transients downloads end up reserving all the available space in the transients directory but not enough to satisfy their individual downloads, then all of them will end up back-off retrying together for more space to become available. However, no space will become available till one of them exhausts the number of backoff-retry attempts -> fails the download -> releases reserved space. Thus, the dagstore will not make any progress with new downloads till one of the download fails and releases it's reservation.

However, this edge case should be mitigated by:

1. Rate limiting the number of concurrent transients fetches
2. Giving higher reservations to older downloads vs newer downloads.

[aarshkshah1992]

Closed in favour of https://github.com/filecoin-project/dagstore/issues/134.