network connection test makes invalid assumptions (hard coded DNS entries)

[fermulator]

Hi team this is a ported (and refined) issue from NeonGeckoCom/neon-os#21

We have uncovered in certain network situations, the Neon OS network connection test utility can false-fail and present the user the perception that "something is wrong" (RED LED, and WiFi seemingly unconfigured when first pulling up the settings).

Additionally the network test can false-pass if the configured system DNS is broken/incorrect, BUT 1.1.1.1 or 8.8.8.8 are accessible.

https://github.com/OpenVoiceOS/ovos-utils/blob/master/ovos_utils/network_utils.py

There are some interesting proposed solutions in that ticket (please take a read through) - but of course the context/reasoning for the current code is not clear to us; and the ovos-utils maintainers may have opinions for how to handle this.

GOAL: (request) here is to ensure that by default, the network tester SHALL use the system configuration to check network connectivity; (and it MAY optionally use "network test configuration" as a fallback or override).

[JarbasAl]

i think we can just drop the dns check, this is something we inherited from mycroft and im not sure what the reasoning was, perhaps just performance?

the solutions for getting system DNS are too complicated and out of scope for utils i think, unless im missing a use case in OVOS that makes it worth keeping this around?

[NeonDaniel]

The linked issue shows a simple method for querying system DNS settings; I don't know that it makes any sense to use a configured DNS endpoint by default for connection checks when the system one can be easily queried. If this is out of scope for utils, then these methods will need to be moved/re-implemented in the connectivity events plugin which does differentiate these different states.

[JarbasAl]

The linked issue shows a simple method for querying system DNS settings; I don't know that it makes any sense to use a configured DNS endpoint by default for connection checks when the system one can be easily queried. If this is out of scope for utils, then these methods will need to be moved/re-implemented in the connectivity events plugin which does differentiate these different states.

the dns check util can remain and be updated, but it's up to whoever is using the tools to decide if they want a dns check or a http check. no harm in exposing the various kinds of checks, just make it explicit