Services with Connect sidecar proxies: probably need standardized meta

With Connect, people can enforce security on existing services, which make sense, by protecting upstream to be connected only from localhost for instance.

So, for an existing service called:

`my-user-service`, we might choose to allow connections only from localhost for instance, by listening only on 127.0.0.0 for instance.
The corresponding `my-user-service-sidecar-proxy` then would be used by connect clients with TLS and intention, good for security.

But by doing this, we basically render `my-user-service` useless to outside world. Even more complicated, on existing services, we might choose to transition slowly from 'classic' services to 'upstream' connect services, so, only one part of the service would be addressable the old way, while the other part (aka the security enforced could not be joined by IP:PORT.

Furthermore, it is complicated for a system to decide whether it should use Connect or not to connect to a service. It is possible, but in that case, you have to check whether MY-SERVICE-sidecar-proxy exists for a given instance.

This is confusing, because this is not the model people have in mind aka: if the instance of a service is healthy in Consul, I can probably connect to it.

What do you think about in the catalog to:
- modify the target service of a Connect service is created on it by specifying for instance a Service Instance Metadata such as `'__connect': 'NameOfConnectServiceName'` (or maybe just write `__connect: true`)
- standardize another meta such as `__connections_allowed: false|true` to explain the initial service can be targeted or not (for instance of services when the `listen` has been enforced to 127.0.0.0) ?

Having those standardized (even in simple service.meta or in a similar way as Service.Weights would allow to load-balancers to take decisions such as "I know the service is up and running, but I should use consul connect to use this instance".

What do you think?