Cardano Updates

  Enable custom P2P bootstrap configuration for multi-node testing:
  - Add IPFS_BOOTSTRAP_PEERS environment variable support for custom peer lists
  - Update bootstrap() to accept optional custom peers parameter
  - Add initialize-p2p.sh script to extract peer IDs and generate bootstrap config
  - Update hermes-ipfs dependency from 0.0.6 to 0.0.8

  This allows nodes in Docker environments to bootstrap to each other
  instead of public IPFS nodes, enabling isolated P2P testing.

* tables

* wip

* proposals dao tests

* bump db schema

* db index name fix

* migration -> use createAll()

* update migration

* update migration

* chore: remove print

* update ref dto flatten implementation

* migration toFlatten()

* fix: proposals dao

* fix: documents dao and local drafts dao

* chore: clean up TODO

* fix: failing tests

* chore: markdown order

* web: skips for db tests

* fix: db tests on web

* fix: analyzer

* unskip tests

* feat: filtering author on first version

* change filter name from author to originalAuthor

* Adds originalAuthor filter to documentsDao

* authorId -> originalAuthorId

* originalAuthors

* fix: spelling

* use authors from documents for originalAuthors

* mithril-aggregator-client from `0.1.3` to `0.1.4`
* mithril-client from `0.12.35` to `0.12.36`
* mithril-common from `0.6.31` to `0.6.32`

By sending them in the client directly instead of in the queries.

Queries can add context throught additional key/value pair by
overloading the `entry_log_additional_fields` method.

<!-- Describe your change here -->

🔑 Motivation

> Closes [#2286](https://github.com/cardano-scaling/hydra/issues/2286)

This PR introduces new synchronization tracking (wall-clock time) and
input-handling logic to improve consistency between the chain component
and node state.

---

🔄 Changes

* `NodeState` has been refactored into a sum type with two variants:
`NodeInSync` and `NodeCatchingUp`.

* A new policy based on the configured `ContestationPeriod` has been
introduced, defining the period of time after which the node is
considered out of sync with the chain. Beyond this period, the node will
refuse to process new transactions or sign snapshots.

* The **head logic** now processes inputs only when the node state's
current slot falls within the safe `ContestationPeriod` window relative
to the latest chain time observed by the chain backend and the current
wall-clock time.

+ **NodeState** transitions between `NodeInSync` and `NodeCatchingUp`
according to the above policy.

  + While in `NodeInSync`, the head logic behaves as usual.

  + While in `NodeCatchingUp`:
      - **Client inputs** are **rejected** if outside the window.
      - This is the starting state.

- **Network inputs** are **re-enqueued** (with TTL) until
synchronization is restored.
⚠️ THIS IS PROBLEMATIC: the network component must be aware of the node
state synced status and accept messages only while `NodeInSync`.

* The **API server** now notifies clients via new server outputs when
the node state falls out of sync with the chain backend and when it
becomes synchronized again.

---

📝 Notes

* We use the wall-clock time and not the latest known tip from the
chain, as it is unreliable while the chain backend is still
synchronizing with the Cardano network.

* A party member cannot go offline for longer than the configured
`ContestationPeriod`; otherwise, it would be at risk, as it would be
unable to contest the head closing. This violates the principle of head
safety.

* We decided to move forward with this _alternative_ solution rather
than the _main proposed one_ because it preserves the node architecture
and allows for fast and easy testing of the protocol’s safety without
requiring major hacks during end-to-end tests. This approach also makes
the protocol safe by design and aware of the passage of time relative to
the latest on-chain observations.
---

<!-- Consider each and tick it off one way or the other -->
* [x] CHANGELOG updated or not needed
* [x] Documentation updated or not needed
* [x] Haddocks updated or not needed
* [x] No new TODOs introduced or explained herafter

---------

Co-authored-by: Sebastian Nagel <[email protected]>
Co-authored-by: Noon <[email protected]>

Signed-off-by: mineme0110 <[email protected]>

With the currently selected generation sizes, we hit the different
voting rules in a somewhat decent proportion, even against randomly
generated functions as part of the PerasVotingView interface.

ouroboros-consensus
  Peras
    Peras voting rules
      isPerasVotingAllowed: OK (1.55s)
        +++ OK, passed 10000 tests.

        Actual result (10000 in total):
        60.29% NoVoteReason(VR-1A or VR-2A)
        20.90% NoVoteReason(VR-1A or VR-2B)
         9.60% VoteReason(VR-2A and VR-2B)
         4.93% VoteReason(VR-1A and VR-1B)
         2.67% NoVoteReason(VR-1B or VR-2A)
         1.61% NoVoteReason(VR-1B or VR-2B)

        Should vote according to model (10000 in total):
        85.47% False
        14.53% True

        VR-(1A|1B|2A|2B) (10000 in total):
        21.30% (False,True,False,False)
        21.24% (False,False,False,False)
        10.63% (False,False,True,False)
        10.27% (False,True,True,False)
         8.99% (False,False,False,True)
         8.76% (False,True,False,True)
         4.67% (False,True,True,True)
         4.26% (False,False,True,True)
         1.93% (True,False,False,False)
         1.77% (True,True,False,False)
         1.71% (True,True,True,False)
         1.61% (True,False,True,False)
         0.75% (True,True,True,True)
         0.74% (True,False,False,True)
         0.70% (True,True,False,True)
         0.67% (True,False,True,True)

        VR-1A (10000 in total):
        90.12% False
         9.88% True

        VR-1B (10000 in total):
        50.07% False
        49.93% True

        VR-2A (10000 in total):
        65.43% False
        34.57% True

        VR-2B (10000 in total):
        70.46% False
        29.54% True

Rename ogmiosRequestSemaphore to ogmiosRequestRateLimiter