Fix issue with choosing a client addr that is 0.0.0.0 or ::

[mkeeler]

This fixes some issue where using the default client address of 0.0.0.0 or a custom one of :: will cause watch plans and managed proxies not to communicate correctly back with the agents HTTP api.

Extra logic was added into the RuntimeConfig class to generate a set of client addresses and in the process convert 0.0.0.0 -> 127.0.0.1 and :: -> ::1.

In addition to the extra tests which cover the default cases of having a client address of 0.0.0.0 or :: some manual test I did included.

• Tested watch plan with HTTPs only API and default client addr connects to 127.0.0.1 over HTTPS
• Tested watch plan with HTTPs only API and client addr of :: to ensure it connects using ::1
• Tested watch plan with HTTPs only API and client addr of 10.X.Y.Z to ensure it connects using that address
• Tested watch plan with HTTPs only API and multiple client addresses to ensure any non-ANY addresses were preferred.
• Tested connect proxy with HTTPs only API and all of the scenarios.

[mitchellh]

Looks good, I don't see anything that stands out as wrong and the test coverage looks great, but I also don't 100% understand the impl/problem so more eyes would be good.

[mkeeler]

@mitchellh The problem was that the logic added recently to tell proxies and watches about the correct http(s) address of the API didn't account for those addresses being 0.0.0.0 or :: which the API client cannot connect to. For those cases we should just select 127.0.0.1 or ::1 as the API address to use.

This is similar to what @banks did recently when choosing a address to use for the tcp health checks of the managed proxy.

[banks]

I thought I'd approved this already. Good job Matt.