[Robust Fabric Config] Refactor client configuration

[aklenik]

Context

This issue is part of the Fabric network configuration schema refactoring task.

Currently, a client can be configured in multiple ways.

Using a wallet

In this case, only the org is needed, everything else is forbidden.

wallet: path/to/wallet
clients:
  client0.org1.example.com:
    client:
      organization: Org1

Loading existing credentials

The certs and keys are already generated, and their paths must be specified. Also, a credential store must be configured

clients:
  client0.org1.example.com:
    client:
      organization: Org1
      credentialStore:
        path: "/tmp/hfc-kvs/org1"
        cryptoStore:
          path: "/tmp/hfc-cvs/org1"
      clientPrivateKey:
        path: path/key.pem
      clientSignedCert:
        path: path/User1@org1.example.com-cert.pem

Registering and enrolling a client dynamically

In this case, the client is registered and enrolled runtime through a CA (a credential store is also needed). It needs an affiliation string and optionally some attributes.

clients:
  client0.org1.example.com:
    client:
      organization: Org1
      credentialStore:
        path: "/tmp/hfc-kvs/org1"
        cryptoStore:
          path: "/tmp/hfc-cvs/org1"
      affiliation: aff1
      attributes:
      - name: departmentId
        value: sales
        ecert: true

Only enrolling an already registered user

This is a rare case but could happen. In this case, an enrollment secret is needed (plus the credential store).

clients:
  client0.org1.example.com:
    client:
      organization: Org1
      credentialStore:
        path: "/tmp/hfc-kvs/org1"
        cryptoStore:
          path: "/tmp/hfc-cvs/org1"
      enrollmentSecret: secretString

Actual Behavior

These modes are mutually exclusive. However, they're specified on the same hierarchical level in the configuration, which makes their validation and usage cumbersome.

Possible Fix

Since neither modes (apart from the wallet) are part of the CCP of the SDK, we can group them however we want.

clients:
  client0.org1.example.com:
    client:
      organization: Org1
      credentialStore:
        path: "/tmp/hfc-kvs/org1"
        cryptoStore:
          path: "/tmp/hfc-cvs/org1"
      loadCryptoMaterials:
        clientPrivateKey:
          path: path/key.pem
        clientSignedCert:
          path: path/User1@org1.example.com-cert.pem
     registerAndEnroll:
       affiliation: aff1
       attributes:
       - name: departmentId
         value: sales
         ecert: true
     enroll:
       enrollmentSecret: secretString

Benefits

The functional behavior is unchanged, but it's much easier to check mutual exclusion among the different modes. And since the related properties are grouped under their respective mode property, accessing them becomes more natural and readable.

Your Environment

• Version used: 0.1.0

[nklincoln]

replaced with #940