Warning: This build has drifted.
The coverage report for this pull request build may be inaccurate because its base commit is no longer the HEAD of its target branch.
This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

    • Learn more: For more information on this, see Tracking coverage changes for pull request builds.
    • Fix now: For a quick fix, rebase this PR at GitHub. Your next report should be accurate.
    • Prevent going forward: To avoid this issue with future PRs, see these Recommended CI Configurations.

add UUID field to commitments

It is a historical mistake of mine that we exposed numerical IDs on
commitments in the first place. We should have UUIDs here to avoid
exposing the number of commitments to non-privileged users, and as
defense in depth against enumeration attacks.

Because commitments of some sort will start appearing in LIQUID soon,
I want to right this wrong before it seeps into the LIQUID API. LIQUID
will only ever refer to commitments by UUID, and the Limes v2 API will
also move to only using UUIDs. The v1 API will show both identifiers to
aid in the migration.

For tests, a facility is added to generate UUIDs in deterministic ways,
similar to what we already have for commitment transfer tokens.

An additional complication presents itself in type
CommitmentWorkflowContext: Currently, commitments refer to other
commitments by numerical ID here. I'm adding UUIDs here on top of the
existing RelatedIDs field, with the intention of eventually fully
replacing RelatedIDs with RelatedUUIDs. However, we will need a
migration period here: We cannot backfill existing contexts with the
UUIDs of the related commitments, since some of those superseded or
expired commitments have already been garbage-collected from the DB.