feat(fabric): serialization of ccp and sshconfig

[jagpreetsinghsasan]

Commit to be reviewed

feat(fabric): serialization of ccp and sshconfig

Primary Changes
---------------
1. sshConfig and connectionProfile can now be passed as base64 encoded strings

Changes required to incorporate 1)
---------------------------------
2. Added sshConfigBase64Encoded and connectionProfileBase64encoded properties to IPluginLedgerConnectorFabricOptions
3. Added necessary FabricConnector class variables
4. Added a new testcase to demonstrate the same
5. Updated an implementation which fetches sshConfig from class variable

Fixes #3577

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.

[outSH]

I've left two open questions, please have a look :)

[outSH]

Can we accept connectionProfile as discriminated union? Something like: {type: "base64", profile: "XXX"}. I was thinking about adding a method for returning connection profile from a connector (as part of #3554) and this common union type could be used as a return value as well. Also, it will be more extensible if we decide to support more connection profile formats in the future (no need to bloat the options with more optional options). And finally this will simplify checking if connection profile was provided after all.

[jagpreetsinghsasan]

@outSH an interesting suggestion in my opinion! If we see the functionality of returning connection profile from the connector itself, in a production grade fabric-network, then I think it will be very hard to create a connection profile as, creation of connection profile will make our connector tightly coupled with the infrastructure where HL Fabric is deployed. This is because, the main problem in publishing such network level configuration always end up in the question of "who will be providing what part of the information" and it then messes up with the overall governance.
Maybe we can instead request that information from the underlying ledger itself as a pre-requisite (in our case, straightaway fetch from the AIO itself without having another function for the same in our connector and we do have that function in the test tooling class for fabric aio).
My only point here being, whenever there is a requirement which deals with the entire ledger level information such as who provides what part of that info, which channel is used to provide that info and where is such an info stored like questions, it becomes very challenging to deal with. So integrating such functionality with our connector will pose future challenges to decouple it again.
This is just my point of view, what do you suggest @petermetz @outSH ?

[outSH]

For return method: I was thinking about maintaning same format for clarity (even if it's fetched from current ledger state), but now that you've mentioned it, that would be very wastefull way because most information contained in a connection profile are useless from network topology point of view, so I think I'll use different output :)

Nevertheless I think the following still applies:

Also, it will be more extensible if we decide to support more connection profile formats in the future (no need to bloat the options with more optional options). And finally this will simplify checking if connection profile was provided after all.

[jagpreetsinghsasan]

I agree.

[petermetz]

^^ Agreed as well. @jagpreetsinghsasan @outSH

[petermetz]

LGTM with comments

[petermetz]

@jagpreetsinghsasan Is there anything preventing us from definitively assigning these fields in the constructor so that we don't need the ! syntax?

[jagpreetsinghsasan]

I declared that this field cannot be null via ! syntax, then assigned this field in the constuctor from the 2 possible options, either from the usual sshConfig or from the base64 encoded version of it and finally controlled the flow using Checks.truthy(this.sshConfig != null, ${fnTag}:sshConfig);
I did it in this way as the other way would be to declare the var without ! and then do some workaround to address the issue of variable is used before assigning

In short, leveraged the use of Checks.truthy( ) alongwith var! to have precise declaration.
Please let me know if this has some flaws/vulnerability or there exists a better way to do the same.

[petermetz]

@jagpreetsinghsasan The if conditions can be refactored this way and then the compiler no longer has an issue with us dropping the ! (which should only be used if there is no way to avoid it due it turning off a safety feature of the compiler):

if (this.opts.sshConfig) {
    this.sshConfig = this.opts.sshConfig;
} else if (this.opts.sshConfigB64) {
    const sshConfigBuffer = Buffer.from(this.opts.sshConfigB64, "base64");
    const sshConfigString = sshConfigBuffer.toString("utf-8");
    this.sshConfig = JSON.parse(sshConfigString);
} else {
    throw new Error("Cannot instantiate Fabric connector without SSH config");
}

I'm guessing the other class member could be refactored the same way so that it does not need the !

[petermetz]

^^ Agreed as well. @jagpreetsinghsasan @outSH

[petermetz]

@jagpreetsinghsasan The if conditions can be refactored this way and then the compiler no longer has an issue with us dropping the ! (which should only be used if there is no way to avoid it due it turning off a safety feature of the compiler):

if (this.opts.sshConfig) {
    this.sshConfig = this.opts.sshConfig;
} else if (this.opts.sshConfigB64) {
    const sshConfigBuffer = Buffer.from(this.opts.sshConfigB64, "base64");
    const sshConfigString = sshConfigBuffer.toString("utf-8");
    this.sshConfig = JSON.parse(sshConfigString);
} else {
    throw new Error("Cannot instantiate Fabric connector without SSH config");
}

I'm guessing the other class member could be refactored the same way so that it does not need the !

[petermetz]

LGTM, thank you for the updates!

[petermetz]

@jagpreetsinghsasan We are almost there! Please fix the tests that started failing. I saw this in the logs:

AIL packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/run-transaction-endpoint-v1.test.ts (177.176 s, 1102 MB heap size)
  ● runs tx on a Fabric v2.5.6 ledger › runs tx on a Fabric v2.5.6 ledger

    Cannot instantiate Fabric connector without connection profile.

      292 |       this.connectionProfile = JSON.parse(connectionProfileString);
      293 |     } else {
    > 294 |       throw new Error(
          |             ^
      295 |         "Cannot instantiate Fabric connector without connection profile.",
      296 |       );
      297 |     }

      at new PluginLedgerConnectorFabric (packages/cactus-plugin-ledger-connector-fabric/src/main/typescript/plugin-ledger-connector-fabric.ts:294:13)
      at Object.<anonymous> (packages/cactus-plugin-ledger-connector-fabric/src/test/typescript/integration/fabric-v2-2-x/run-transaction-endpoint-v1.test.ts:158:20)