[FAB-3995] /examples/cluster: Fix TLS support

Chaincode currently fails to instantiate when TLS is enabled.
Two root causes were identified:

1) We were setting CORE_PEER_ADDDRESSAUTODETECT=true, which was
forcing the peer to advertise an IP rather than a DNS name to the
chaincode instance.  Since only the DNS names are registered in
the x509 for the peer, the TLS layer was rejecting the peer's cert.
We fixed this by disabling ADDRESSAUTODETECT

2) Enabling DNS revealed that the chaincode was executing on a
different docker network from the peer.  The biggest implication
was that DNS resolution for things like "peer1" was not possible.
Thus, fixing (1) broke us in a different way.  We fixed this by
setting the environment properly such that the peer launches
chaincode on the proper network.

Fixes FAB-3995

Change-Id: I1ebfbf43b63b2d288aaee7c098ebdb1f8bd5c352
Signed-off-by: Greg Haskins <gregory.haskins@gmail.com>

examples/cluster/compose/peer-base/peer-base.yaml

@@ -9,6 +9,7 @@ services:
       - CORE_NEXT=true
       - CORE_PEER_ENDORSER_ENABLED=true
       - CORE_PEER_GOSSIP_BOOTSTRAP=peer1:7051
+      - CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=compose_default
     volumes:
       - /var/run/docker.sock:/var/run/docker.sock
     command: peer node start --peer-defaultchain=false

examples/cluster/config/core.yaml

@@ -66,7 +66,7 @@ peer:
     address: 0.0.0.0:7051
     # Whether the Peer should programmatically determine its address
     # This case is useful for docker containers.
-    addressAutoDetect: true
+    addressAutoDetect: false
 
     # Setting for runtime.GOMAXPROCS(n). If n < 1, it does not change the current setting
     gomaxprocs: -1