Fix faucet

[GabrielMartinezRodriguez]

Description

This PR solves multiple issues in the faucet:

• The first issue was that the faucet wasn't being monitored by the monitor service, so ironically it ran out of funds.

• Another issue fixed was that the faucet was limiting usage based on both successful and failed transactions. Now it only considers successful transactions.

• The threshold in the monitor service was increased because it was previously equal to the amount of tokens sent per request. This could cause problems if multiple users requested funds at the same time.

• A race condition was fixed in the transaction manager (TXM) where the same transaction was sent multiple times. This caused the faucet to occasionally send duplicate transactions for a single request. The issue occurred because the transaction was being monitored in the TXM before the collection process had fully completed.

• TXM traces are now exported from the faucet to allow debugging in case of issues.

Toggle Checklist

Checklist

Basics

• B1. I have applied the proper label & proper branch name (e.g. norswap/build-system-caching).
• B2. This PR is not so big that it should be split & addresses only one concern.
• B3. The PR targets the lowest branch it can (ideally master).

Reminder: PR review guidelines

Correctness

• C1. Builds and passes tests.
• C2. The code is properly parameterized & compatible with different environments (e.g. local,
  testnet, mainnet, standalone wallet, ...).
• C3. I have manually tested my changes & connected features.

< INDICATE BROWSER, DEMO APP & OTHER ENV DETAILS USED FOR TESTING HERE >

< INDICATE TESTED SCENARIOS (USER INTERFACE INTERACTION, CODE FLOWS) HERE >

• C4. I have performed a thorough self-review of my code after submitting the PR,
  and have updated the code & comments accordingly.

Architecture & Documentation

• D1. I made it easy to reason locally about the code, by (1) using proper abstraction boundaries,
  (2) commenting these boundaries correctly, (3) adding inline comments for context when needed.
• D2. All public-facing APIs are documented in the docs.
  Public APIS and meaningful (non-local) internal APIs are properly documented in code comments.
• D3. If appropriate, the general architecture of the code is documented in a code comment or
  in a Markdown document.
• D4. An appropriate Changeset has been generated (and committed) with make changeset for
  breaking and meaningful changes in packages (not required for cleanups & refactors).

[cloudflare-workers-and-pages]

Deploying happychain with    Cloudflare Pages

Latest commit:	79781af
Status:	✅  Deploy successful!
Preview URL:	https://6e6d3c71.happychain.pages.dev
Branch Preview URL:	https://gabriel-fix-faucet.happychain.pages.dev

View logs

[GabrielMartinezRodriguez]

• Fix faucet #983 👈 (View in Graphite)
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[norswap]

Suggested change

	export FUNDS_TO_SEND=10000000000000000
	export FUNDS_TO_SEND=100000000000000000

Let's also increase the funds to send to 0.1 HAPPY — this will avoid topping up the faucet every time someone pulls from it (the faucet sents 0.01 HAPPY), instead topping up once every 10 pulls.

[norswap]

Waiting 5 blocks might introduce a lot of lag in our retries.
I'm retooling this so that we mark transaction that haven't gone through the initial submission as a new TransactionStatus.NotAttempted and we filter to not process these transactions in the TxMonitor.