Scan: Reward accounting root-hash and activity-totals return three values

[dfordivam]

Modified the following endpoints to return "undetermined" and "cannot-compute" values, in addition to the result.

• /v0/reward-accounting-process/rounds/{round_number}/activity-totals
• /v0/reward-accounting-process/rounds/{round_number}/root-hash

As discussed last week with Simon and Robert; these are the criterion for the return value selection.

• undetermined
  returned if scan does not see any CalculateRewardsContract with a round number <= the queried round
  or if the root hash (and associated data) is not found in the store
• cannot-compute
  if scan does not have a complete set of activity records for the round

But in the code the "undetermined" is actually a catch-all case, because even if the CalculateRewardsV2 exist for this round, and the scan is yet to compute the totals, "undetermined" would still work since the sv-app would retry.

As these are internal endpoints, marked as "subject to change", the existing /v0 endpoints have been modified, and PR has no release-notes mention. (original addition of these endpoints also did not have release-notes entry)

  /v0/reward-accounting-process/rounds/{round_number}/root-hash:
    get:
      tags: [internal, scan]
      x-jvm-package: scan
      operationId: "getRewardAccountingRootHash"
      description: |
        SV node internal API (CIP-0104, subject to change).
        Returns the root hash computed for the specified round.

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).

[dfordivam]

@meiersi-da This is a small change we discussed last week. I have originally done this as part of my integ test PR, but took this out in this separate PR on main.

The change was in fact necessary to get the CI green by avoiding unnecessary error logging from the CalculateRewardsTrigger when it just needed to retry the fetch.

[meiersi-da]

Thanks a lot.

[meiersi-da]

need to check whether doing BFT calls for this endpoint using the standard code path works as expected, as deviations in the responses are expected. I suspect we might be logging mismatches too aggressively.

Nothing to do right now, but something to be aware of.

[dfordivam]

Yes, at the moment this is just to compile the code. When the triggers actually use BFT client, we will have to circle back to these concerns.