Remove DNS handling from all C modules except `net.dns`.

[nwf]

This is actually an anti-feature request. Handling DNS in C is a pain and a source of object lifecycle bugs in our tree.

• net.dns gets it right, though the documentation asserts that there is only one callback in flight at once, which appears false. I'll add that to my next stack of cleanups.

• net's socket handling at least tries to get it right, using wait_dns to continue to pin the userdata in the registry until the DNS callbacks have fired. This is entangled in its state machine, which is pretty messy.

• tls gets it wrong, at the time of this writing, possibly referencing freed memory if the user completely drops a tls socket while a DNS operation is in progress.

• mqtt and websocket behave similarly, following pointers to possibly-dead memory.

Anyway, I'd like to simplify the C world by removing any pretense of doing DNS and require that the Lua application use net.dns whenever DNS resolution is requisite. Note that, for example, coap already does not support DNS, and even net's support is restricted to TCP and not UDP.

[pjsg]

This raises an issue with sntp as the default invocation with (essentially) no arguments works well at the moment. It does need to resolve some dns names.

[nwf]

Good call. sntp.c dodges the lifecycle issue by having a static state object and not pinning anything to the Lua registry; as such, it's exempt from my ire in this anti-feature request. ;)
(And, FWIW, #2819 presently uses the net.udp dns function, but would be easy to make use net.dns instead.)

[marcelstoer]

I'd like to simplify the C world by removing any pretense of doing DNS and require that the Lua application use net.dns whenever DNS resolution is requisite.

Purely speaking as a firmware user now: this is... no, please don't do this. No network library/framework I know of has an API that accepts IP addresses only. It would be a grand step backwards.

Handling DNS in C is a pain and a source of object lifecycle bugs in our tree.

Can't this be extracted into a shared piece of code that modules can include? I agree, it shouldn't be the module's responsibility to address cross-cutting concerns.

[nwf]

You're right; this is an over-reaction on my part. Threading reference counts around tls was not terrible; doing so for everybody else is probably a matter of a few days' half-hearted work.