feat: Add centrifuge vault tests SUP-7374 + New architecture of Async State Registry to handle user-based aggregated processing SUP-7583 + Perform scenario testing with selective chains + SUP-7745

[0xTimepunk]

Async 7540 vaults that use constant Request Ids of 0 follow an aggregated model when handling user (controller) requests into the claimable step.

Due to this nature, a payload by payload processing as originally existent on TimelockStateRegistry and adapted into the first version of AsyncStateRegistry does not work well. The main reasons for this are:

• Partial movements into claimable state by the vault are possible
• User can go directly to the vault and perform requests directly, increasing claimable amounts. This value, which would be read by the keeper could induce invalid or undesired processing of payloads. An example could be as follows:

  
  Action 1:

• 1000 USDC deposit request goes through superform from user 1
• it is claimed directly in centrifuge by user 1 (claimable amount becomes 0)
• Payload id 1 remains pending in state registry(!)

Action 2:

• 1000 USDC deposit request again by the same user 1, this time directly through centrifuge.

• Claimable on this deposit becomes ready

• Keeper on our side (who operates the 2nd step) sees this fact and processes payload Id 1 (which was pending), rugging the user by becoming the shares owner and minting superPositions (unintended effect by the user)

• Also, there can be slight differences (observed of 1 Wei at least) between the assets that were actually deposited in the requestDeposit step, vs what later becomes claimable (if we consider a full claim)

For all these reasons we decided to revamp the AsyncStateRegistry into a processing by user/superformId pair. This, coupled with an architecture of setting RequestConfigs for each one of these pairs, would allow a keeper to claim the entire amount claimable with the desired user settings. The settings would be overwritten on each new incoming payload from the ERC7540Form in the 1st step via the function updateRequestConfig. The other functions claimAvailableDeposits and claimAvailableRedeems were refactored. The 7540Form stayed mostly the same.

This PR is still in process as some important checks are still missing with the new implementation, but it is indicative of the final intended architecture (which processes as long as there's a claimable amount >0 for a given user/superformId)

[linear[bot]]

SUP-7374 Add Centrifuge Real vaults once deployed to a live sepolia

[linear[bot]]

SUP-7583 Decide on the final architecture / UX of 7540 Async State Registry

[linear[bot]]

SUP-7745 Add centrifuge new real vault and update protocol actions tests/helper functions