feat(copm): add Corda COPM implementation

[jenniferlianne]

Primary change:

Implements COPM primitives for Corda as a cacti plugin. The implementation follows the model of
the Corda ledger connector plugin, where a typescript pass-through implementation is registered on the plugin server, and commands are implemented on a separate grpc server in the Kotlin Spring framework.

Secondary changes:

• The lock claim protobuf structure was updated to reduce the number of parameters.
• A no-op endpoint was added, per project specification
• The format of the inter-network command for requesting the status of a pledge varies by remote network type and asset. Adds a function to the typescript interop configuration interface to supply the appropriate command given the remote network and asset.
• Adds test package to test combinations of network types
• Updates CI script to use new testing framework
• Updates linter ignore to include weaver build directories, allowing yarn lint to pass on a system where weaver libraries have been built. Also excludes docs directory to avoid linting minified js from documentation packages.

Pull Request Requirements

• Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
• Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
• Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

• Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
• Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

[petermetz]

@jenniferlianne Looking pretty high quality in general, but as usual I have some requests. On top of the comments I left inline, please make sure to include a test case which verifies the plugin being functional while used through the API server (you'll most likely need a separate package because this one cannot depend on the API server due to circular dependency issues)
If you need examples just let me know.

[petermetz]

@jenniferlianne LGTM, thank you!

[jenniferlianne]

@jenniferlianne Looking pretty high quality in general, but as usual I have some requests. On top of the comments I left inline, please make sure to include a test case which verifies the plugin being functional while used through the API server (you'll most likely need a separate package because this one cannot depend on the API server due to circular dependency issues) If you need examples just let me know.

As mentioned on the call, the plugin is brought up via the ApiServer in both fabric and corda cases. Please see:
packages/cacti-copm-test/src/main/typescript/corda/copm-tester-corda.ts line 118
packages/cacti-copm-test/src/main/typescript/fabric/copm-tester-fabric.ts line 122

[sandeepnRES]

@jenniferlianne Thank you for the PR, overall looks good to me. Just some small suggestions above I've shared.

[VRamakrishna]

Please rename this to chaincodeName.

[sandeepnRES]

Probably networkName instead of network in the below line 21?

[jenniferlianne]

After further discussion on the project channel I have removed the chaincode and flowPackage variables from the remote network configuration struct as remote networks may use multiple chaincode packages in both fabric and corda. The network variable has been renamed networkName.

[sandeepnRES]

Hi @jenniferlianne I'm not sure about the purpose of this type RemoteNetworkConfig, but even the channelName and corda party endpoints could also be different for every remote call for the same network, as there can be multiple channels (as discussed on discord).
I believe you have taken this from fabric-cli which was a tool for testing purpose, but since this is a main package to be used by others, I would recommend to make it as general as possible.

Its okay if you can just open an issue to track this.

[jenniferlianne]

As discussed with @VRamakrishna 2 weeks ago, the naming, which is consistent with a similar structure in the fabric implementation submitted 3 months ago, reflects the data structures in the weaver test network json configuration files. While named 'network', they seem to talk about organizations, not networks. While I may be wrong, I expect this information will not change on the fly for a given organization. Can rename to RemoteOrganizationConfig.

[sandeepnRES]

Lets it be as it is for now, just open an issue to track this, so that we can think about it more later, if we actually need restructuring.

[jenniferlianne]

Too late - I updated the naming to be RemoteOrganization, as well as using 'organization' instead of 'network' for AssetAccounts in the OpenApi spec. The code is more consistent now. I opened an issue here for revisiting in the future: #3656