Add flush mechanism

[GabrielMartinezRodriguez]

Linked issues

closes https://linear.app/happychain/issue/HAPPY-250/only-flush-transactions-that-have-been-modified

Description

This PR aims to add a mechanism to avoid re-updating transactions that have no changes

Key changes:

• Added pendingFlush and notPersisted field to track database persistence
• Consolidated updateTransaction, updateTransactions, and saveTransactions into a single saveTransactions method

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).

Correctness

• C1. Builds and passes tests.
• C2. The code is properly parameterized & compatible with different environments.
• C3. I have manually tested my changes & connected features
• C4. I have performed a thorough self-review of my code.

Architecture & Documentation

• D1. I made it easy to reason locally about the code.
• D2. All public-facing APIs & meaningful internal APIs are properly documented.
• D3. If appropriate, the general architecture is documented.

[cloudflare-workers-and-pages]

Deploying happychain with    Cloudflare Pages

Latest commit:	6d6cd5c
Status:	✅  Deploy successful!
Preview URL:	https://b1523595.happychain.pages.dev
Branch Preview URL:	https://gabriel-flush-mechanism.happychain.pages.dev

View logs

[GabrielMartinezRodriguez]

• Add flush mechanism #289 : 2 dependent PRs (#297 , #298 ) 👈 (View in Graphite)
• Allow run multiple txm simultaneously within the same service #285
• Added docs for txm #272
• Mutex in tx monitor #264
• Purge transactions #232
• Txm hooks #229
• Use kysely instead of mikro-orm #250
• master

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

[linear]

HAPPY-250 Only flush transactions that have been modified

#250 (comment)

[norswap]

I think we should reorder the fields above, such that the fields from TransactionConstructorConfig come first, followed by the rest.

I'm not quite clear on why the distinction exists at all btw, what's the thinking there?