Fix RFC 7049 canonical CBOR map key ordering and add property test

[carbolymer]

Changelog

- description: |
    Fix RFC 7049 canonical CBOR map key ordering and add property test
# uncomment types applicable to the change:
  type:
  # - feature        # introduces a new feature
  # - breaking       # the API has changed in a breaking way
  # - compatible     # the API has changed but is non-breaking
  # - optimisation   # measurable performance improvements
  # - refactoring    # QoL changes
   - bugfix         # fixes a defect
   - test           # fixes/modifies tests
  # - maintenance    # not directly related to the code
  # - release        # related to a new release preparation
  # - documentation  # change in code docs, haddocks...
# uncomment at least one main project this PR is associated with
  projects:
   - cardano-api
  # - cardano-api-gen
  # - cardano-rpc
  # - cardano-wasm

Context

This PR reverts partially changes made to the test in: https://github.com/IntersectMBO/cardano-api/pull/1047/files

It also adds a property test, which recursively validates canonicalisation of CBOR accordingly to CIP-21.

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated. See Running tests for more details
• Self-reviewed the diff

[Jimbo4350]

You are weakening the unit_canonicalise_cbor property test. Why not leave it as it is and just add your prop_canonicalise_cbor property?

[carbolymer]

@Jimbo4350 correct. That's because the test felt too complicated to understand and debug. Now that part of the code is covered by prop_canonicalise_cbor test, so we are not losing test coverage here.

[Jimbo4350]

@Jimbo4350 correct. That's because the test felt too complicated to understand and debug. Now that part of the code is covered by prop_canonicalise_cbor test, so we are not losing test coverage here.

We are losing ease of debuggability. Removing inputMapInIndefiniteList and inputMapInDefiniteList from unit_canonicalise_cbor makes it more difficult to determine if the canonicalization failed due to a CBOR round trip or the canonicalization itself (for those terms). assertWith eventually calls assert which will give us less information vs a direct comparison against the hardcoded TMap in unit_canonicalise_cbor.

Your new property will fail and only render the value that failed:

assertWithM :: (H.MonadTest m, Show p, HasCallStack) => p -> (p -> m Bool) -> m ()
assertWithM v f = GHC.withFrozenCallStack $ do
  result <- f v
  if result
     then H.success
     else do
       noteShow_ v
       H.assert result

I agree it's not easy to read but it can be cleaned up.

[github-actions]

This PR is stale because it has been open 45 days with no activity.

[Copilot]

Pull request overview

This PR updates the CBOR canonicalisation test suite to add targeted unit tests plus a new property test that recursively checks canonicalisation (intended to align with CIP-21 / RFC 7049 canonical ordering rules).

Changes:

• Replaces the previous single canonicalisation property with three deterministic “unit” properties covering maps and maps inside definite/indefinite lists.
• Adds a QuickCheck-driven property that checks canonicalisation is canonical (per a local predicate) and idempotent.
• Introduces helper functions/data (exampleInputMap, exampleCanonicalMap, decodeTerm, key comparator).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[carbolymer]

@Jimbo4350 I've simplified the unit tests, moved out the special cases of list and indefinite list to separate tests unit_canonicalise_indefinite_list and unit_canonicalise_definite_list. Those are redundant IMO, as they are tested by property test already, but if you prefer we can keep them.

A bug also came up where the keys are not sorted by length first instead of just lexicographically. This PR fixes it.