Sponsor Project Claim & Collect transactions

[efstajas]

Depends on #1182

Gas on FVM is extremely cheap, and Gelato Relay will be available (projected by end of August). We can easily cover costs for claiming projects and collecting tokens, which makes those flows entirely gasless, and makes it possible for people to move earned tokens on Drips to their wallet without needing to acquire any FIL.

What we need

• 1182, in order to properly display & propose gasless transactions using the new Transact step

• new logic for signing arbitrary transaction payloads against Caller with the user's wallet (details TBD with Igor). We already have a gasless transaction, requestUpdateOwner, today, but it's anonymous and doesn't get signed by the user.
• new /api/gasless endpoints for 1) submitting the 2nd transaction in the project claim flow (set metadata and splits), and 2) collecting tokens. These endpoints should validate input data thoroughly so that they can not be used to dispatch arbitrary transaction payloads not generated by the Drips app to Gelato. Important: They need to check whether the app instance is actually configured to sponsor the respective transaction for the current network and throw an error if not.
• a new per-network config / env var that allows us to configure which, if any, transactions the app should sponsor.

UX Outline

Claiming project

Below is for the case when the app instance is configured to sponsor all claim & collect transactions on the given network. If it's not, things are generally the same, except the user needs to execute the 2nd transaction rather than it being gasless.

• User enters project claim flow and proceeds to the "Add funding.json" step.
• After the app validates locally that the funding.json is present and valid, it first checks whether the correct owner is already set on-chain, and kicks off the requestUpdateOwner transaction silently in the background through Gelato (as it already does today) only if it's not.
• Once the user gets to the review step and clicks "Confirm in wallet", a transact step appears.
• The user sees the two transactions; update owner and set metadata. Both say that gas is free and sponsored by Drips (#1182).
• The first transaction is already in its processing state. First, the app polls the api/gasless/track endpoint with the taskId of the requestOwnerUpdate TX sent to Gelato earlier. Once it reports the TX as done, the app starts polling the API and waits for it to return the PendingMetadata state for the project.
• Once PendingMetadata is received, the app triggers the signature request for the 2nd transaction. Once the user signs, the payload is sent to Gelato and the app again waits for the task to resolve on Gelato, and then waits for the state of the project to update to Claimed.
• App invalidates local data (as it already does) and presents the user with a link to their newly claimed project.

Collecting

• User enters global collect flow and selects what tokens to collect.
• After confirming, user enters Transact step and sees the single "Collect" TX, with gas fee as 0 and "Sponsored by Drips" (#1182).
• User is prompted to sign the TX in their wallet.
• After relaying the TX with Gelato, app waits for the task to resolve on Gelato, and then waits for the update to be indexed by our API (as it already does).
• App invalidates local data (as it already does) and shows the success screen.

Failure cases

(All errors below must be sent to Sentry in addition to being caught)

• App tries to kick off the gasless owner update TX in the background after funding.json step, but Gelato returns an immediate error. In this case, the user should see an error like "Failed to update on-chain owner gaslessly. Please try again or reach out to us on Discord." and be prevented from continuing the flow.
• App calls api/gasless/track to check on the state of a gasless TX and sees that the transaction failed for whatever reason. In this case, the app should halt the process and display an inline error on the Transact step that says something like "The gasless transaction failed. Please try again in a few hours or reach out to us on Discord."
• App has been polling the state of a gasless TX for over 5 minutes. The process should time out and display an inline error on the Transact step that says something like "The gasless transaction wasn't confirmed after 5 minutes. Please try again in a few hours or reach out to us on Discord."
• Gasless TX was successful but polling the Drips API doesn't return the expected state after over 5 minutes: The process should time out and display an inline error on on the Transact step that says something like "Project username/project-name not in expected state state after 5 minutes. Please try again in a few hours or reach out to us on Discord."

[efstajas]

Summary for claiming gaslessly on FVM with rate limiting:

• User enters project claim flow and enters project URL.
• After funding.json step, client calls the gasless API endpoint for requesting a repo owner update.
• The server applies the IP-based rate limiting.
  • If the request is blocked, return 429.
  • If it passes, continue.
• Server checks current gas penalty.
  • If the penalty is above threshold, it returns 503 with an explicit error code.
  • If not, it kicks off the TX and returns the Gelato Relay task ID for the TX.
• Client handles the response:
  • If 429, display "Sorry, you're doing this too much. Please wait at least one hour and try again" error and block user from continuing the flow.
  • If 503, display an error saying something like "Sorry, a lot of people are using Drips right now and we can't accept any additional repo claims for a short while. Please try again in at least one hour". This error should be very rare, as we will set the gas threshold high enough to handle even larger (realistic) spikes.
  • If successful, client stores Gelato task ID in state and continues walking the user through the flow.
• User arrives at review step and submits. App begins preparing final transaction.
  • First, app checks current status of Gelato Relay task ID for the gasless owner update.
  • If pending, poll every second until reasonable timeout, then throw with descriptive error message.
  • If errored, throw with descriptive error message ("There was an error with Gelato Relay processing the owner update transaction: {error message}")
  • If successful, continue.
  • Next, app polls Drips API until project status returns as PendingMetadata. Again with a reasonable timeout, descriptive error if exceeded.
  • App builds the splits & metadata TX and displays the transaction overview screen with a single transaction called "Claim repository". Displays as "Gas sponsored by Drips" (#1182).
  • App triggers signature request from user's wallet.
  • Once signed, app calls new endpoint that receives the signature and relays it via Gelato gaslessly.
  • Endpoint has same ip-based rate limiting described above.
  • Endpoint also checks that target repo is in expected state.
  • App receives new Gelato Relay task ID and begins polling. Handles timeout and error same as described earlier for the 1st transaction.
  • If successful, app polls Drips API for project being Claimed and sends user to success screen.

On networks where we don't sponsor both transactions (e.g. mainnet) OR if the user is using a Safe, everything is the same as above, except for that the 2nd transaction is proposed to the user's wallet instead of being relayed gaslessly.