feat: ✨ optimize BSP confirm flow

[TDemeco]

This PR makes it so the BSP empties its queue of storage requests to confirm more efficiently, by always trying to send the confirm extrinsic with the maximum amount of confirms allowed by the runtime instead of being happy sending it with less than that.

• Previous behaviour:
  • The confirm task got the list of files to confirm from the blockchain service (through the event that triggered it). If all of the received requests were stale (e.g. the storage request does not exist on chain anymore) then the task exited immediately, but if even one of them were valid it send the extrinsic with it.
  • This made it so the BSP could take the forest lock and send and extrinsic only for one confirm, while the queue might be full of pending confirms to process.
• New behaviour:
  • The confirm task gets the list of files to confirm using the new PopConfirmStoringRequests command, and can then filter them in two lists with the FilterConfirmStoringRequests: the ones ready to confirm and the ones pending that the volunteer extrinsic is included in the blockchain.
  • It then can check if there's the ones ready to confirm are enough to fill up a confirm batch. If so, sends the extrinsic, but if they are not it pops and filters the amount of elements remaining (for example, if from the first pop and filter of 10 elements only 5 storage requests are ready to confirm and the maximum batch amount is 10, it will pop and filter 5).
  • This process repeats until either the queue of pending storage requests to confirm is empty or the amount of storage requests ready to confirm is the maximum allowed by the runtime.
  • Finally, once it sends the confirm extrinsic, it re-queues any elements that were pending a storage request volunteer inclusion.

⚠️ Breaking Changes ⚠️

• Short description

  There is a new new runtime API under the File System pallet: get_max_batch_confirm_storage_requests. Runtime managers of runtimes that use StorageHub will have to implement it.

• Who is affected

  • Runtime managers of runtimes that use StorageHub since the new runtime API has to be implemented

• Suggested code changes

  Implement the runtime API:

  impl pallet_file_system_runtime_api::FileSystemApi<Block, AccountId, BackupStorageProviderId<Runtime>, MainStorageProviderId<Runtime>, H256, BlockNumber, ChunkId, BucketId<Runtime>, StorageRequestMetadata<Runtime>, BucketId<Runtime>, StorageDataUnit<Runtime>, H256> for Runtime {
        ...
        fn get_max_batch_confirm_storage_requests() -> BlockNumber {
            FileSystem::get_max_batch_confirm_storage_requests()
        }
        ...
   }