Configure anonymous token policy for connect

[lkysow]

When running Consul Connect, cross-dc calls require that the anonymous
token has read permissions on all services. This change updates the
server-acl-init command to give the anonymous token those permissions if
connect is enabled.

Since we already set those permissions in the case of dns being enabled,
the change was to also set those permissions in the case of connect
being enabled. To detect connect being enabled, we used the presence of
the -create-inject-auth-method flag since that's set when connect is
enabled.

The policy was renamed from dns-policy to anonymous-token-policy since
it applies for more than just dns now. In existing installations, a new
policy with that name will be created and attached to the anonymous
token that will duplicate the old dns-policy but will have no
detrimental effects.

[ishustava]

Luke, looks good! I left some comments around using connect without DNS and multi-dc setup and a suggestion.

My other question is around upgrading from an existing installation. Since we'll create a policy with the new name, the old dns policy will stay around. I think Consul API allows us to update the policy's name since the update API is using policy's ID. Do you think it makes sense to do that? The risk is that someone is attaching this policy to the tokens we don't manage.

[lkysow]

My other question is around upgrading from an existing installation. Since we'll create a policy with the new name, the old dns policy will stay around. I think Consul API allows us to update the policy's name since the update API is using policy's ID. Do you think it makes sense to do that? The risk is that someone is attaching this policy to the tokens we don't manage.

I think that the increased complexity probably isn't worth it in this case. The policy will still exist and work for the tokens they've attached it to and the policies are the exact same so it's not like they'll miss out on the new rules being attached to those tokens.

[ishustava]

LGTM