Update Nameserver13

[tgreenx]

Purpose

This PR proposes to fix discrepancies in the implementation of Nameserver13 with respect to its specification.

Context

Fixes #1503

Changes

• Change query type
• Remove unneeded conditionals (relates to edns fails for afnic.fr ... seems to be false alert #480, which added checks related to Extended Error Codes but that were not necessary for this test case)
• Add a mention for missing unit tests

How to test this PR

This test case (among others in this test module) currently have no unit test. See
Manual testing:

$ zonemaster-cli --show-testcase --level DEBUG --test nameserver13 --no-ipv6 afnic.fr | grep DNSKEY
   1.63 DEBUG    Nameserver13   System:Nameserver13:EXTERNAL_QUERY flags={"class":"IN","edns_details":{"do":1,"size":512,"version":0},"fallback":0,"usevc":0}; ip=194.0.36.1; name=afnic.fr; type=DNSKEY
   1.64 DEBUG    Nameserver13   IPv6 is disabled, not sending "DNSKEY" query to g.ext.nic.fr/2001:678:4c::1.
   1.64 DEBUG    Nameserver13   System:Nameserver13:EXTERNAL_QUERY flags={"class":"IN","edns_details":{"do":1,"size":512,"version":0},"fallback":0,"usevc":0}; ip=192.134.4.1; name=afnic.fr; type=DNSKEY
   1.65 DEBUG    Nameserver13   IPv6 is disabled, not sending "DNSKEY" query to ns1.nic.fr/2001:67c:2218:2::4:1.
   1.65 DEBUG    Nameserver13   System:Nameserver13:EXTERNAL_QUERY flags={"class":"IN","edns_details":{"do":1,"size":512,"version":0},"fallback":0,"usevc":0}; ip=192.93.0.4; name=afnic.fr; type=DNSKEY
   1.65 DEBUG    Nameserver13   IPv6 is disabled, not sending "DNSKEY" query to ns2.nic.fr/2001:660:3005:1::1:2.
   1.66 DEBUG    Nameserver13   System:Nameserver13:EXTERNAL_QUERY flags={"class":"IN","edns_details":{"do":1,"size":512,"version":0},"fallback":0,"usevc":0}; ip=192.134.0.49; name=afnic.fr; type=DNSKEY
   1.67 DEBUG    Nameserver13   IPv6 is disabled, not sending "DNSKEY" query to ns3.nic.fr/2001:660:3006:1::1:1.

[marc-vanderwal]

Suggested change

	if ( $p->rcode eq q{FORMERR} ) {
	if ( $p->rcode eq q{FORMERR} and not $p->has_edns ) {

A non-EDNS FORMERR response means the server does not support EDNS, in which case it is appropriate to generate a NO_EDNS_SUPPORT message. But an EDNS-enabled FORMERR response means something else: that the server understood that the query is an EDNS query, but it is malformed. In that case we should generate NS_ERROR.

[tgreenx]

Maybe so, but that is not what the current specification is saying and this PR was about correcting discrepancies. I'm fine with reverting this change though until a proper specification update is done.
@matsduf thoughts?