Add DB versions of Splice.Amulet.CryptoHash

[adetokunbo]

First part the changes that address #4382

• split out because it's a specific change that can be reviewed on its own

Pull Request Checklist

Cluster Testing

• If a cluster test is required, comment /cluster_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.
• If a hard-migration test is required (from the latest release), comment /hdm_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.
• If a logical synchronizer upgrade test is required (from canton-3.5), comment /lsu_test on this PR to request it, and ping someone with access to the DA-internal system to approve it.

PR Guidelines

• Include any change that might be observable by our partners or affect their deployment in the release notes.
• Specify fixed issues with Fixes #n, and mention issues worked on using #n
• Include a screenshot for frontend-related PRs - see README or use your favorite screenshot tool

Merge Guidelines

• Make the git commit message look sensible when squash-merging on GitHub (most likely: just copy your PR description).

[meiersi-da]

Please also add a corresponding test that calls the actual Daml functions.

I'd do so by adding a Splice.Amulet.TestTemplates module defining a template CryptoHashProxy that allows evaluating calls to crypto hashes.

[adetokunbo]

Fixed.
Needed to

• change the build files to allow com.digitalasset.canton.util.TestEngine to be run by splice tests cdf0afe
• inline the daml functions in the proxy class; they will be removed when this branch is merged with the actual daml changes (part of 80cc9d9)

[rautenrieth-da]

Looks good, I'm only slightly nervous about the test strategy. We are comparing the SQL output to a re-implementation of the daml code in scala, with only two hardcoded hashes manually copied from the daml output. I think it's still fine because we don't expect changes in #3964, but I'd like to hear input on this from @meiersi-da.

Unfortunately I don't think it's possible to execute arbitrary daml functions from scala code. We have an in-memory daml engine (com.digitalasset.canton.util.TestEngine) but that takes a command and produces a transaction.

[meiersi-da]

Looks good, I'm only slightly nervous about the test strategy. We are comparing the SQL output to a re-implementation of the daml code in scala, with only two hardcoded hashes manually copied from the daml output. I think it's still fine because we don't expect changes in #3964, but I'd like to hear input on this from @meiersi-da.

Unfortunately I don't think it's possible to execute arbitrary daml functions from scala code. We have an in-memory daml engine (com.digitalasset.canton.util.TestEngine) but that takes a command and produces a transaction.

We can and should test the equivalence to the Daml implementation.

I'd suggest to do this as follows:

1. Add module Splice.Testing.AmuletComputationProxies to splice-amulet-test
2. Add the following template to that module (and fix the bugs due to sketching this directly here)

template ComputeCryptoHash with
  owner : Party
  where
    nonconsuming choice ComputeCryptoHash_HashMintingBalances : Hash
      with
        input : MintingBalances
      controller owner
      do pure (hash input)

   ... add choices for the other calls you want to check

3. Create one instance of it, and then submit commands against it to get the exercise result and thus the Daml compute value.

[adetokunbo]

@rautenrieth-da , @meiersi-da all comments addressed, PTAL

[rautenrieth-da]

Thanks, test coverage looks good now!

(don't forget to add the signed-off-by to the last commit)

[rautenrieth-da]

For a test like this is good enough. For production code, you can avoid all unsafe interpolation and manual quoting using

(
  sql"select " ++ sql"daml_crypto_hash_text($v)" ++ ...
).toActionBuilder

[meiersi-da]

I'm wary of this dependency, as it is only available because we fork Canton.

I'd much prefer to just use the normal participant nodes we have available, and thereby be safe both from divergences in the behavior as well as be safe from having to be able to provision this dependency.

[meiersi-da]

@rautenrieth-da : wdyt?