Clarify error handling around fallback from advanced to direct

The draft currently suggests that a WKD client should fall back from the advanced URL to the direct URL:

Implementations MUST first try the advanced method. Only if the required sub-domain does not exist, they SHOULD fall back to the direct method.

Is this test intended to mean that the presence of an openpgpkey.example.com DNS record (A or AAAA) is sufficient to avoid falling back to the direct method? There are several situations where naive WKD clients may find it difficult to distinguish this case from other cases. For example:

• openpgpkey.example.com has an NS delegation, but the authoritative DNS servers for the subzone are not responding.
• openpgpkey.example.com has no A or AAAA records.
• only AAAA records exist, but the WKD client only has an IPv4 address.
• some address record exists, but the client sees a routing failure trying to connect to it.
• the client can reach the intended endpoint, but port 443 is closed or not responsive
• the client can connect on port 443, but the TLS handshake fails.
• the client can make a successful TLS handshake but receives unparseable HTTP traffic
• the client sends an HTTP response that is anything other than 404 or 200

Somewhere in this continuum is a cutline where we definitely want clients to fall back to "direct" mode, but different clients might choose the cutline differently. In that case, an active network adversary may be able to force some clients to fall back to the "direct" URL, but not others.

If we can provide more specific guidance to implementers so that they know how to handle the fallback case, the protocol will be more predictable for users across different WKD clients.