Make Claim Project flow smart about what transactions to trigger when

[efstajas]

(Depends on #1187)

Currently, the transaction triggering behavior of the Claim Flow is as follows:

• After the "Add funding.json" step, if the file is found and validated client-side, it makes a request to an API endpoint that triggers a gasless requestUpdateOwner TX via Gelato. Since this transaction is anonymous, it doesn't require a signature from the user.
• Once the user gets to the review step and confirms, we wait for the status of the project to change to PendingMetadata. It reaches this step as soon as the oracle updated the owner and that TX has been indexed.
• Once in PendingMetadata state, we trigger a transaction that sets splits and updates project metadata in the user's wallet.
• After that second transaction is confirmed, we wait for it to be indexed, and then send the user to the success step.

There are two main failure cases that we're not handling gracefully here:

1. Gelato Relay may be down, in which case the API call that triggers the gasless owner update will return an error. This currently results in the user seeing an error step and being unable to proceed past the "add funding.json" step.
2. Gelato Relay may be working fine, but the gasless requestUpdateOwner TX may be stuck and / or actually fail. This could happen for example if our Gelato 1Balance ran out. In this case, it still accepts the "job", but that job eventually ends up in an error state. We have an API endpoint in the app already for checking job states at /api/gasless/track/< task ID>.

We should make the claim flow smart about handling both of these cases.

Case 1 It should swallow the error (but forward to Sentry), and let the user proceed. At the end of the flow, it should recognize that the owner update request hasn't yet been made, and propose that transaction to the user instead, before waiting for the project state to update to PendingMetadata.

Case 2 It should check for the state of the Gelato job right before triggering transactions at the end of the flow. If the job hasn't succeeded, it should also propose the requestOwnerUpdate TX to the user before waiting for the project state to update to PendingMetadata.

[efstajas]

The changes described here are now part of #1187.