Allow a workload access to the parsed support of the network configuration so that it can query information

[davidkel]

Ensure it is a cloned copy so the workload can't make dynamic changes, This would be useful for the workload so that it knows of

1. The identities available
2. The MSPs available (for org targeting for example)
3. The peers available in an MSP (for specific peer targeting when implemented, eg to write custom load balancers for an individual client)
4. the chaincodes and channels available

This would allow for a very dynamic fabric workload indeed, not sure of a use case at present but interesting for quick experimental purposes such as trying to quickly distribute load across gateway peers. Or perhaps to have a worker switch between MSPs randomly to simulate driving load from different organisations.

[aklenik]

@davidkel If you only want the network configuration file content that Caliper parsed, then workload modules can access the network configuration path through the core's config-util module (one of the root keys). It's a quick workaround to grab the raw YAML until the connector provides a parsed object graph.

Although the static network configs are usually a bit lightweight since the discovery service, so it might be more useful to return the network structure that was dynamically explored (can we get that from the gateway SDK?).

[davidkel]

@aklenik unfortunately there is no discovery api in the new fabric-gateway sdk (as it is so lightweight and all the work is done in the peer now), we would need to write our own grpc client for this. It is available in the old deprecated and archived sdks, so going forward the only quick option would be for the workload to have it defined somewhere and the parsed network config from the connector seemed like as good as place as any.