Limit the input for srv records using the API

[leonnicolas]

Adjacency works fine when not passing a different srv record when using curl.

However, the result of this call to an adjacency pod has some issues

curl ip_of_ajacency_pod:8080/?srv=_imaps._tcp.gmail.com.

All adjacency pods will make an http request to something like http://imap.gmail.com:993/ping
They will just get errors when making the request. Most likely a connection reset by peer. Technically, there is still a tcp handshake where the peer sends the RST flag to reset the connection. Should we use this to determine the duration?

What if a srv record uses udp as a protocol?

An alternativ would be to make a real ping probe, But that would only go to the host/container and not the specific service.

If we don't want to use a real ping, we should limit the input srv to tcp protocol only and if we don't want to use a failed http request due to a "reset by peer" error, we should limit the service to http in the srv records.

[squat]

It's not really possible to use UDP, since it is by definition connection-less. However, for the other cases, we could define a Prober interface and implement types that all expose a Probe method for timing various kinds of connections. When we get back a list of SRV records we could switch on the supported protocol and attempt various checks in decreasing order of confidence. For example:

1. if http is supported, first try to use the adjacency-curl /ping endpoint
2. if http is supported, try to make a request and return the time it took to get any response
3. if tcp is supported, try to measure the time until a RST or anything is received
   The reason for not simply doing all probes with tcp from the beginning is that it may be less accurate in the case that the node in question is behind some proxy, router, or other network apparatus that responds to the TCP connection but doesn't forward to the actual server in question.