We want to reuse these generic DNS concepts in resolved hook
implementations, hence move them to shared code.

(This also enables us to immediately remove som SVCB record handling
duplicate definitions.)

No real code changes, just some moving around of things.

The DNS RR class is a weird thing, and IRL always set to IN (i.e. 0x1).
Let's hence make it something that can be specified optionally, and
imply IN if not specified.

This makes it a bit nicer to put together suitable json resource record
keys from the command line.

This introduces /run/systemd/resolve.hook/ as a new directory that local
(privileged) programs can bind a Varlink socket into. If they do they'll
get a method call for each attempted resolved lookup, which they can
then either process themselves (and generate new records for, or return
errors to block stuff) or let pass so that the regular resolution is
done.

Usecase for this is primarily two things:

1. in machined we can add local resolution of machine names to their IP
   addresses, similar in fashion to nss-mymachines, but working also if
   the non-NSS interfaces to name resolution are used, i.e. the local
   DNS responder. In fact, I think we should eventually remove
   nss-mymachines from our tree, as soon as this code in resolved is
   setlled.

2. in networkd we can add local resolution of names specified in DHCP
   leases we hand out.

But beyond that there should be many other uses, for example people
could write "dns firewalls" with this if they like where they
dynamically block certain names from resolution.

Fixes: systemd#8518

…more readable

This basically implements nss-myhostname, but natively in
systemd-resolved, so that the logic becomes available also for clients
using the local DNS stub for resolution or the D-Bus or Varlink APIs.

…data

Let's synthesize DNS RRs for leases handed out by our DHCP server. This
way local VMs can have resolvable hostnames locally.

This does not implement reverse look ups for now. We can add this
later in similar fashion.

This function doesn't "connect" to Varlink (i.e. it isn't a client) but
it binds a Varlink socket (i.e. it is server), hence let's remove the
verb "connect" from its name. let's copy how machined/resolved name the
counterpart for this function: manager_varlink_init()

Let's expose local VMs/containers under ._dhcp by default. Let's also
expose WIFI AP clients under .home.arpa (i.e. the RFC8375 domain for
home networks).