add queryDRepDelegations ledger state query

[rrruko]

Description

This adds a ledger state query to obtain the delegators (and deposit) for each DRep, including DRepAlwaysAbstain and DRepAlwaysNoConfidence, which cannot be queried via the existing queryDRepState. Since there is no sensible expiry or anchor for those DReps, a new type is introduced that is like DRepState but with those fields omitted. The result is computed by folding over the UMap.

This would be useful for amaru; see for example this comment.

Checklist

• Commits in meaningful sequence and with useful messages.
• Tests added or updated when needed.
• CHANGELOG.md files updated for packages with externally visible changes.
  NOTE: New section is never added with the code changes. (See RELEASING.md).
• Versions updated in .cabal and CHANGELOG.md files when necessary, according to the
  versioning process.
• Version bounds in .cabal files updated when necessary.
  NOTE: If bounds change in a cabal file, that package itself must have a version increase. (See RELEASING.md).
• Code formatted (use scripts/fourmolize.sh).
• Cabal files formatted (use scripts/cabal-format.sh).
• CDDL files are up to date (use scripts/gen-cddl.sh)
• hie.yaml updated (use scripts/gen-hie.sh).
• Self-reviewed the diff.

[lehins]

First of all, let me say thank you for a very nice contribution.
I can certainly see how this query can be useful, but there are some surprising things that I have some questions about.
Also, unfortunately, it is a bad timing to add such a query, because we are on a verge of replacing UMap in favor of a more accurate and simpler representation in #5128
It doesn't mean we can't add this query. It's just I would recommend addressing all other comments in this PR first and then we can change the implementation in the query itself once the above PR is merged.

[lehins]

This query is exactly what we had discussed. Hopefully it was simpler to work with new AccountState abstraction, rather than the older UMap representation.
Most of my suggestions should lead to a slightly simpler implementation, but the end result should be the same.

[lehins]

Beautiful! Thank you for your hard work!
Could I ask you one last thing. Could you please create couple of tickets on:

1. https://github.com/IntersectMBO/ouroboros-consensus
2. and https://github.com/IntersectMBO/cardano-api

that mentions the need to integrate this query all the way to cardano-cli

[lehins]

One last comment and it needs fourmolu applied: https://github.com/IntersectMBO/cardano-ledger/actions/runs/16891288070/job/47946964522?pr=5176

[rrruko]

Beautiful! Thank you for your hard work! Could I ask you one last thing. Could you please create couple of tickets on:

1. https://github.com/IntersectMBO/ouroboros-consensus

2. and https://github.com/IntersectMBO/cardano-api

that mentions the need to integrate this query all the way to cardano-cli

Should we create a ticket in cardano-cli too?

[lehins]

Should we create a ticket in cardano-cli too?

Yes, it would be good too! Although, I think if cardano-api adds a query, I believe compiler will force cardano-cli to account for it as well.