Interface specific RA DNSSL option behaviour

[Daniel Gröber]

Hi BIRDies, 

I was playing with RA and DNSSL options today. I found the order of DNSSL
options generated unhelpful.

My config looks something like this:

```
protocol radv {
  dnssl {
    domain "global1.example";
    domain "global2.example";
  };
  interface "enp2s0" {
    dnssl {
      domain "interface.example";
    };
  };
}
```

and I see the following RA options being generated (as shown by rdisc6):

    DNS search list          : global1.example global2.example
     DNS search list lifetime:         1800 (0x00000708) seconds
    DNS search list          : interface.example
     DNS search list lifetime:         1800 (0x00000708) seconds


I tested with dhcpcd and rdnssd and saw problems with both: 1) dhcpcd
outright doesn't support multiple DNSSL options so I only got the first one
in /etc/resolv.conf (working on reporting) and 2) rdnssd supports this but
the list in /etc/resolv.conf ends up being:

    search global1.example global2.example interface.example

While rdnssd's behaviour seems in-line with RFC 8106 it's not what I wanted
to achive overall.

See section 6.3. "Synchronization between DNS Search List and Resolver
Repository", https://datatracker.ietf.org/doc/html/rfc8106#section-6.3.

> [...] it stores the DNSSL domain names (in order) [...]

My goal was to have interface.example be the LAN domain (i.e the first in
the search list) and the rest of the domains last in the search list.

Admittedly this is a weird use-case and global dnssl was probably just
intended for the simple case of all interfaces having the same search
domain.

If I had multiple LANs and corresponding domains I would not be able to
share the list in the global dnssl option anyway, this really only works
with LAN domains and network-wide search domain in the global list.

I know I can fix this using the `dnssl local` switch (I tried and it works
as expected), but perhaps a new option to give the order I want would be
useful for others?

Thanks,
--Daniel