feat(copm): add fabric COPM implementation

[jenniferlianne]

Primary Change:

• add connectRPC cactus plugin for copm primitives

Secondary Changes:

• add common COPM prototypes
• add common weaver protos-js directory to enable building under ci.yaml, which requires all local
  dependencies to be present at build time
• remove incorrect 'main' declaration in protos-js package file
• add separate tsconfig file to /weaver/sdks/fabric/interoperation-node-sdk to
  allow it to be built by ci.yaml
• update weaver fabric network makefile 'clean' target to continue if some target files
  were not generated by the make process

Signed-off-by: Jennifer Bell jenniferlianne@gmail.com

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.

[sandeepnRES]

Sorry I don't have context about this structure, but why are these numbers so high?
Usually proto structures start with 1, 2 and so on...

Same comment for all the below proto files.

[jenniferlianne]

The pb files are generated from openapi, following cactus convention. The openapi desc is here: https://jenniferlianne.github.io/cacti/references/openapi/cacti-copm-core_openapi/,

[VRamakrishna]

@jenniferlianne Can you follow the suggestion in OpenAPITools/openapi-generator#9646 to set field numbers starting from 1? That will make the proto message files more readable.

(I don't want this to block the merge of this PR though. If it's inconvenient, you can revise this in the next PR.)

[petermetz]

@jenniferlianne Very high quality PR overall, thank you very much for the contribution! I left a few comments with my usual nit picks but it's definitely looking great already! Congratulations!

[sandeepnRES]

API Name isn't updated here

[petermetz]

@jenniferlianne LGTM, thank you very much!

[VRamakrishna]

@jenniferlianne Can you also check the documentation (with names updated as per your discussion with @sandeepnRES) from https://jenniferlianne.github.io/cacti/references/openapi/cacti-copm-core_openapi/ into this PR? That way, when we add code to the main repo, there is (at least some) documentation explaining what it does.

(BTW....sorry for my late comments. I've still not recovered from my illness, and am taking it slow.)

[jenniferlianne]

@jenniferlianne Can you also check the documentation (with names updated as per your discussion with @sandeepnRES) from https://jenniferlianne.github.io/cacti/references/openapi/cacti-copm-core_openapi/ into this PR? That way, when we add code to the main repo, there is (at least some) documentation explaining what it does.

(BTW....sorry for my late comments. I've still not recovered from my illness, and am taking it slow.)

The openapi documentation should be generated under this link https://hyperledger-cacti.github.io/cacti/references/openapi/ when the code is merged. An updated preview (with the changes discussed) is here: https://jenniferlianne.github.io/cacti/references/openapi/cacti-copm-core_openapi/

[sandeepnRES]

LGTM

[petermetz]

@jenniferlianne Please resolve the merge conflict and make sure to update the package versions to match the latest release which was just issued

[VRamakrishna]

I see the pledge-network and lock-network targets in the Makefile doing the same thing currently. I guess you will differentiate them in a later PR?

Also, I'd like to understand why a network can be instantiated only with on capability (pledge/lock) and not the other. In the legacy Weaver test networks, we launch different example applications (e.g., the simpleasset and simpleassettransfer chaincodes) exclusively to demonstrate the different protocols (asset transfer, asset exchange). But there's no reason why we can't have both running on a network at the same time (a Fabric network can have any number of chaincodes deployed.) The common Fabric chaincode (from which you are drawing the COPM functions) contains the complete set of capabilities, which can be invoked on demand (just like we envision for the COPM).

Anyway, this is not a blocker for the current PR. We can discuss offline.

[VRamakrishna]

Overall, looks very good to me. Very well-written and well-organized code, conforming to the Cactus patterns and the Weaver functionality (as was intended for this integration effort).

Just a couple of comments, one of which (proto field numbering) you can choose to address in this PR or in the next one.