DNS resolution failure not auto resolving

With the 2.0.2 client, when http is being used it seems that every flush instantiates a new connection. This makes sense and therefore does not require any "reconnection" methodology. However, if a dns resolution failure occurs once, then for the life of the Sender it will no longer attempt to resolve.

Specifically, there is a scenario where when a pc boots, a service we use for networking may not be connected yet. In this case, dns resolution may fail for 30 seconds or so. However, if the Sender has been created and a flush already called then it seems the DNS failure is in someway cached and it never is attempting to resolve the dns again. This is the error I received:

questdb.ingress.IngressError: Could not flush buffer: http://kronus-nexus:4900/write?precision=n: Dns Failed: resolve dns name 'kronus-nexus:4900': failed to lookup address information: Temporary failure in name resolution

Then, for the life of the code, it keeps having the same error and is never able to reconnect again. But then if I change nothing but just restart the code, then dns resolves just fine and everything works as intended. Also, if I change the address to a hard coded ip, then it will also auto connect after the network service is up and runs just fine. This is a working solution for me for now but it does not seem intended that a single dns failure will result in a Sender that is forever in a failure state.

Start with the Sender lifecycle and flush path described in the report, reproducing a transient DNS failure followed by network recovery. Trace how the HTTP hostname-resolution error persists across flushes; done means a later flush retries DNS and succeeds without restarting the Sender. Add coverage for this failure-and-recovery sequence if the existing test structure supports it.