Support for granting ValidatorLicense via SV UI

[dfordivam]

Fixes #2904

• Adds support for granting ValidatorLicense via SV UI and console.

• Show weight + License kind in ValidatorLicense UI

  • Weight will only be shown if it is non-null
  • A check-mark will be shown if it is a validator node operator

• Scan API fixes: ValidatorReceivedFaucets

• And includes scala code fixes for the daml changes introduced in Daml: Add weight, kind to ValidatorLicense, and SV grant license support #2903

• Adds a column in dso_acs_store for storing ValidatorLivenessActivityRecord weight

• Removes SvMergeDuplicatedValidatorLicenseIntegrationTest and adds its functionality in new test SvValidatorLicenseIntegrationTest

[dfordivam]

Screenshots (these are old screenshots, ignore)

1. New fields in /validator-onboarding for granting license.
   And Validator Licenses table shows "Weight" and "Non-operator" columns

2. Confirmation prompt when trying to grant a license

3. New License visible in table, along with check-mark for "Non-operator".

4. Error shown when party is invalid

5. Button is disabled when UI detects a typo

6. Scan-app's /validator-licenses also shows new columns

[isegall-da]

@dfordivam I'm confused. I thought we agreed that we're breaking the work into a series of small PRs that one can effectively review. It's very hard to review thoroughly a PR of this magnitude that's a code dump of your complete work.
Specifically, if you have fixes to another PR that's still open, please apply the fixes there instead of including them here, so that every PR is a self-contained and complete unit of work.

[dfordivam]

@isegall-da I would have preferred to change the "base" branch, such that the daml changes included in this branch are not shown in this PR. (I could not set the base to my branch as it is on a fork).
But I guess it would be better to simply remove the daml commits; at least for the review purpose the daml changes need not be present in this PR.

[isegall-da]

@isegall-da I would have preferred to change the "base" branch, such that the daml changes included in this branch are not shown in this PR. (I could not set the base to my branch as it is on a fork). But I guess it would be better to simply remove the daml commits; at least for the review purpose the daml changes need not be present in this PR.

Why can't you base the branch on your own branch? You can stack multiple PRs one on top of the other, thus breaking the work into chunks that a reviewer can digest and review effectively.

[isegall-da]

Alternatively, you can rework the git history in the branch such that it's a series of self-contained commits that one can review one at a time.

[dfordivam]

Why can't you base the branch on your own branch? You can stack multiple PRs one on top of the other, thus breaking the work into chunks that a reviewer can digest and review effectively.

So its just a Github limitation, my branch is on the fork, and the base branch has to be on hyperledger-labs/splice.
The simplest solution in this scenario is to give me access to push branch to this repo. Other workarounds are a bit more complicated or have limitations, as breaking the work such that it does not use commits present in other PRs would limit how much I can practically breakdown changes into reviewable chunks.

[meiersi-da]

I'll review tomorrow morning my time.

[meiersi-da]

@dfordivam : on

wdyt about adding 'default: 1.0' when the weight is not set?

I'd also suggest to invert the double-negation: call the column "Operator" and add a checkmark if its an operator license.

[meiersi-da]

Nice work @dfordivam !

Looks good up to the testing changes and small pieces of missing functionality. Let me know when you've addressed that so I can do a second review.

[dfordivam]

Screenshots

• Main UI

• Valid party-id

• Invalid party-id

• Confirmation prompt

• New validator visible in list

[meiersi-da]

Thanks. Looks good to me modulo the minor suggestions.

Approving with suggestions: https://neilmitchell.blogspot.com/2019/04/code-review-approve-with-suggestions.html

[meiersi-da]

Important: we are mutating the store definition, which is only OK as we are voting in the Daml change after upgrading all SV apps to the new version that supports it.

Please add a corresponding note to the release_notes.rst file in the Upcoming section at the top -- as part of this branch.

[dfordivam]

Ok, I have added this and a few more to a new section for the "Integration branch" in release_notes.rst, This should hopefully avoid conflicts with rebase and allow us to have a glance of "the diff" easily.