Is there no longer any way to know if an endpoint is invalid with this update?
Just wondering why we are deleting tests as opposed to updating them.

Now that FQDNs are supported, there are very few addresses that would be invalid. We could check for things like whitespace or non-printable characters, but that's checking for things the user's unlikely to provide us. The only way to really know if an endpoint is valid is to try to connect to it, and I'd argue that having the same error (failure to connect) for a typo that misspells .com as .con as we do for a typo that adds a space is more consistent behavior.

But there's no way to make StartClient fail because that check is async, and that's what those tests were testing.

So my question is more relating to removing something like this:

        [Test]
        public void UnityTransport_StartClientFailsWithBadAddress()
        {
            UnityTransport transport = new GameObject().AddComponent<UnityTransport>();
            transport.Initialize();

            transport.SetConnectionData("foobar", 4242);
            Assert.False(transport.StartClient());

            LogAssert.Expect(LogType.Error, "Invalid network endpoint: foobar:4242.");
            LogAssert.Expect(LogType.Error, "Target server network address (foobar) is Invalid!");

            transport.Shutdown();
        }

As opposed to just wrapping the part I think you are thinking is no longer valid?

        [Test]
        public void UnityTransport_StartClientFailsWithBadAddress()
        {
            UnityTransport transport = new GameObject().AddComponent<UnityTransport>();
            transport.Initialize();

            transport.SetConnectionData("foobar", 4242);
            Assert.False(transport.StartClient());

#if !HOSTNAME_RESOLUTION_AVAILABLE && !UTP_TRANSPORT_2_4_ABOVE
            LogAssert.Expect(LogType.Error, "Invalid network endpoint: foobar:4242.");
            LogAssert.Expect(LogType.Error, "Target server network address (foobar) is Invalid!");
#endif
            transport.Shutdown();
        }

Where we would still expect the same behavior of the client failing to start if it passed in just "foobar" as the address... which is not FQDN nor an IP... ?

The same would go for DetectInvalidEndpoint.

I am confused about the async part as both UnityTransport.StartClient and UnityTransport.StartServer are non-async methods that are defined within NetworkTransport?

Don't we want to make sure that if you give UnityTransport an invalid address (IP or FQDN) that the transport fails to start?