Resolve should track queries and handlers

[bremoran]

Currently, when a DNS lookup is initiated from a particular socket, an onDNS handler is installed in the socket. However, if a second query is initiated before the first finishes, that can overwrite the original onDNS handler. This creates a race condition on a per-socket basis.

There are three steps to a solution for this problem:

1. Document the race condition and provide a workaround (create a socket for each DNS lookup)
2. Provide a mechanism for escalating function pointer/void* pairs to full C++11 functors (including lambdas, etc.)
3. Provide a DNS lookup API that does not require a socket.

C Function escalation mechanism

It is common practice to provide the DNS callback with a void* user-supplied callback.

This could be used to supply a object/function pair, though this does not account for virtual inheritance. The Function API could provide a convenient abstraction for this problem, allowing a C function pointer with a void * context object to escalate to a full C++11 call, including lambdas, etc.

Providing this abstraction requires a three class-static API functions provided by the Function class:

• get_reference() obtains a void * pointer to the target functor and increment a the reference count
• call_from_void() Translates a void * back to a FunctionInterface * and calls it
• call_from_void_dec() Exactly the same as call_from_void(), except that it also decrements the reference count.

DNS lookup API

The DNS lookup API currently uses the Socket instance as a proxy for discovering the stack in use. This is unnecessary and makes the API more cumbersome. In single-stack environments, resolve() can be a free function. In multi-stack environments, it can be:

1. a free/static function that iterates through stacks until a match is found
2. a free/static function that takes either a stack index or a stack ID
3. a function bound to each network interface
4. a function bound to the socket, that requires an open socket (the current status-quo)

Option 1) seems to be the least cumbersome option.

cc @bogdanm @adbridge @autopulated @0xc0170

[ciarmcom]

ARM Internal Ref: IOTSFW-1903