Unbound can unexpectedly decide that a forwarder does not support EDNS, breaking all DNSSEC validation

[nomis]

Describe the bug Unbound has unexpectedly decided that the primary forwarder for . does not support EDNS (ednsknown 1 edns -1):

# unbound-control dump_infra
10.0.0.1 . ttl 1689 ping 7 var 10 rtt 50 rto 50 tA 0 tAAAA 0 tother 0 ednsknown 1 edns -1 delay 0 lame dnssec 0 rec 0 A 0 other 0
2a02:8010:633d:0:44d3:22ff:fe06:7dee . ttl 621 ping 0 var 94 rtt 376 rto 120000 tA 1 tAAAA 0 tother 3 ednsknown 1 edns 0 delay 0 lame dnssec 0 rec 0 A 0 other 0
...

The result is that it never sets the DO flag and then complains that every response is missing signatures. It is configured with another IP for the same forwarder but it hasn't attempted to prefer that one (ednsknown 1 edns 0) over the one that it thinks can no longer support EDNS.

To reproduce Unknown. There are no log messages indicating why it has decided to do this, it just started reporting validation failures for everything:

2022-05-28T17:11:37.116+01:00 unbound@krull/info unbound[2189]: [2189:0] info: validation failure <grafana.com. A IN>: no DNSSEC records from 10.0.0.1 for DS grafana.com. while building chain of trust
2022-05-28T17:11:42.070+01:00 unbound@krull/info unbound[2189]: [2189:1] info: validation failure <grafana.com. AAAA IN>: key for validation grafana.com. is marked as invalid because of a previous validation
 failure <grafana.com. A IN>: no DNSSEC records from 10.0.0.1 for DS grafana.com. while building chain of trust
2022-05-28T17:12:01.179+01:00 unbound@krull/info unbound[2189]: [2189:1] info: validation failure <grafana.com. AAAA IN>: no DNSSEC records from 10.0.0.1 for DS grafana.com. while building chain of trust

Expected behavior

• Unbound should log when it decides that a configured forwarder doesn't support EDNS.
• Unbound should prefer the other forwarders that it still thinks support EDNS.
• It should be possible to configure unbound to never downgrade its decision on EDNS support for forwarders.

System:

• Unbound version: 1.6.7
• OS: Ubuntu 18.04
• unbound -V output:

  Version 1.6.7
  linked libs: libevent 2.1.8-stable (it uses epoll), OpenSSL 1.1.1  11 Sep 2018
  linked modules: dns64 python subnetcache respip validator iterator

Additional information The forwarder is also running Unbound 1.6.7.

[nomis]

In both places where it decides that the host should be recorded as not supporting EDNS, it checks to see if the query requested DNSSEC.

That's inappropriate if unbound is configured to validate all queries by default. In that scenario it shouldn't matter what individual queries want - the forwarder must always support EDNS.