Add support for chaincode as a service

[jt-nti]

Description

Fabric has supported chaincode as a server for some time and recent chaincode updates have made this simpler.
One advantage is that it is much easier to debug chaincode running as a server, rather than where fabric manages the lifecycle of the chaincode.
This would be a good option to re-enable debug support in the extension: see #2660

Unfortunately there is currently no support for chaincode as a server in the extension.

Possible Fix

There are currently two options for packaging chaincode...

There would need to be an additional tar.gz option for chaincode as a server.

Deploying a chaincode as a server smart contract is then essentially the same however instead of fabric starting the contract, it must be started manually. It would probably be best to start the contract using the standard vscode debug tools but that may not be immediately obvious. One possibility would be to add information to the deploy steps...

There may also be changes required in the chaincode projects generated by generator-fabric.

[jkneubuh]

@jt-nti thanks this is a great feature. Seems like a short and effective path to debugging chaincode in a local IDE.

One thing to consider is in how the chaincode package defines the connection URL for the service endpoint. If the extension is working with a minifab network locally, it seems plausible to get a route back to the local host where the CC endpoint has bound the gRPC socket.

But what about cases where the Fabric network is running remotely, where the VSCode is on a development workstation behind NAT / firewall / etc, and the peer has no network route the CC gRPC socket?

Can the extension somehow register the chaincode URL during the "deployment" process / workflow?

This would allow a local developer to start a reverse proxy (or connect via a dedicated relay like ngrok.com) and debug CC as if it were resident within the cluster, adjacent to the peer.

[jt-nti]

Thanks @jkneubuh, good point. I was just thinking about the built in microfab networks but needs to take into account running remotely as well.

[jt-nti]

See #3183