Add custom resolver support for v2 Address messages

[htuch]

In the v2 API, we allow Address messages to specify a resolver plugin. This will transform logical addresses to concrete addresses. This supports address virtualization and address namespaces that are non-standard. This issue will track the implementation of the registration facility, invocation of the resolver at appropriate code sites and an example resolver for testing.

The resolver should be capable of returning an arbitrary Address::Instance subclass, which will be able to support a notion of a string representation for both the logical and physical address. These can then be plumbed into logs, stats and generated headers as distinct concepts.

[akonradi]

This seemed straightforward until I started looking at the already-existing-but-unrelated DNS resolver, which resolves names asynchronously. It seems like that's the right way to resolve names in general, but the code paths that would use this expect config parsing to be a synchronous affair.

[htuch]

I guess the question is how dynamic do we need to be? We could do resolution at config ingestion time, which would probably be fine for Google, but the general resolver scheme would probably also support this happening at bind/connect time. I'd be fine with a synchronous config time load resolution as a first step, because that's all that Google needs.

The use cases for the resolver so far have been IP NAT and port name mapping (from a named port to a specific port). I think there was also the idea we would use SRV in the Address for existing DNS resolution, but that can follow the existing path.

[htuch]

Thinking about how onConfigUpdate() works today, the interface is very synchronous. Would it be simpler to do the resolution at bind time (caching results for performance)?

[akonradi]

We could defer resolution until bind(), connect(), or ip() are called if they're already treated as blocking methods. A fancier implementation could even start an asynchronous request when the Instance is first created to reduce the amount of time spent blocking, but that might be overkill.

[akonradi]

After talking with @htuch in person, this is going to stay completely synchronous for now - no remote lookups, no network access. The calling code could be modified to support asynchronous lookups, but it would require significant changes and a lot more callbacks sprinkled around.

[mattklein123]

@htuch @akonradi +1 let's keep it simple/synchronous unless we have a clear need for something else.

[mattklein123]

I think this is done. Closing.