Add a DNS query diagnostic check to VNet

[ravicious]

The problem

VNet on macOS now checks for conflicting routes (#43232 (comment)). In a situation where a 3rd-party app uses the Network Extension macOS framework and sets up routes that conflict with VNet, this diag check is able to precisely identify which app is causing problems. However, there are some problems with it:

1. The implementation is platform-specific.
2. Other software might prevent VNet from working correctly even if there are no conflicting routes.

Namely, if other software creates a DNS resolver that has higher priority than VNet's resolver, VNet is not going to receive DNS traffic.

VNet doesn't create network routes and resolvers with a super high priority (#51778 (comment)). Unlike traditional VPN software, it doesn't need to capture all traffic, just traffic to specific DNS zones, hence why it's susceptible to being broken by VPN apps.

The solution

We can detect if VNet is receiving DNS traffic by always creating a resolver for a specific DNS zone, say teleport-vnet.test, and then make our DNS nameserver respond to a query for that zone with some specific IPv6 and IPv4 addresses, e.g. any IPv6 address under our prefix and the IPv4 address of our nameserver.

A VNet client can receive get the IPv6 prefix and the IPv4 address of the nameserver during initialization. During a diagnostic run, it can send a DNS query for teleport-vnet.test with a timeout of 2-3s and then compare the response to the addresses received earlier.

This method should be platform agnostic as it's just going to use code from the net package and no platform-native APIs. A separate teleport-vnet.test zone is chosen instead of something like test.vnet.dns.<cluster DNS zone> because technically VNet can be started without the user being logged in to any cluster.

If you're thinking to yourself "Why didn't we implement this first and leave the conflicting routes for later?", it was bad planning on my part.