Before:

   $ /nix/store/ihlzjcxahcack6chfzphb74bkccmq6br-dart-2.7.2/bin/dart2native hello.dart
   Failed to generate native files:
   ProcessException: No such file or directory
     Command: /nix/store/ihlzjcxahcack6chfzphb74bkccmq6br-dart-2.7.2/bin/utils/gen_snapshot --snapshot-kind=app-aot-elf --elf=/tmp/HSHJQU/snapshot.aot /tmp/HSHJQU/kernel.dill

After:
   $ /nix/store/czw7kpdmcqa76a9j00v2pjygrq7gy4c7-dart-2.7.2/bin/dart2native hello.dart
   Generated: /home/thiagoko/hello.exe

   $ ./hello.exe
   Hello, World!

Also remove interactive flag from initrd, because of broken io.

I hope I bumped all attributes correctly.

This matches a similar change made to Firefox in #96767.
A lot of code is shared between Firefox and Thunderbird
so it makes sense to increase timeouts for Thunderbird
as well.

Apparently, v0.1.4 was released twice. The current version of the build
points to the first edition of v0.1.4, which is no longer attached to
the tag "v0.1.4" on GitHub. Hence currently, downloading fails.
This commit adjusts the hash to appropriately refer to the second
edition of v0.1.4

Merges both patches previously applied. Also seems to change the path that the library is written to.

Systemd has to remain an optional (non-default) dependency as otherwise
we will have an unpleasant bootstrap cycle. Most (if not all) of the
(lib)unbound consumers will likely not care about unbound's systemd
integration that only affects the daemon mode, anyway.

This introduces an unbound variant that is built with systemd support.
That means it is able to signal readiness to systemd once it did start
or finished reloading. This likely allows us to close a small gap during
bootup where the service is assumed up but doesn't respond to DNS
queries just yet.

Previously we just applied a very minimal set of restrictions and
trusted unbound to properly drop root privs and capabilities.

With this change I am (for the most part) just using the upstream
example unit file for unbound. The main difference is that we start
unbound was `unbound` user with the required capabilities instead of
letting unbound do the chroot & uid/gid changes.

The upstream unit configuration this is based on is a lot stricter with
all kinds of permissions then our previous variant. It also came with
the default of having the `Type` set to `notify`, therefore we are also
using the `unbound-with-systemd` package here. Unbound will start up,
read the configuration files and start listening on the configured ports
before systemd will declare the unit "running". This will likely help
with startup order and the occasional race condition during system
activation where the DNS service is started but not yet ready to answer
queries.

Aditionally to the much stricter runtime environmet I removed the
`/dev/urandom` mount lines we previously had in the code (that would
randomly fail during `stop`-phase).

The `preStart` script is now only required if we enabled the trust
anchor updates (which are still enabled by default).

Another beneefit of the refactoring is that we can now issue reloads via
either `pkill -HUP unbound` or `systemctl reload unbound` to reload the
running configuration without taking the daemon offline. A prerequisite
of this was that unbound configuration is available on a well known path
on the file system. I went for /etc/unbound/unbound.conf as that is the
default in the CLI tooling which in turn enables us to use
`unbound-control` without passing a custom configuration location.

Both of the configured paths should be implicit due to RuntimeDirectory
& StateDirectory.

This option allows users to specify a local UNIX control socket to
"remote control" the daemon. System users, that should be permitted to
access the daemon, must be in the `unbound` group in order to access the
socket. When a socket path is configured we are also creating the
required group.

Currently this only supports the UNIX socket mode while unbound actually
supports more advanced types. Users are still able to configure more
complex scenarios via the `extraConfig` attribute.

When this option is set to `null` (the default) it doesn't affect the
system configuration at all. The unbound defaults for control sockets
apply and no additional groups are created.

As part of this patch series a few changes have been made to the unbound
serivce the deserve proper documentation.

Other units depend on nss-lookup.target and expect the DNS resolution to
work once that target is reached. The previous version
`wants=nss-lookup.target` made this unit require the nss-lookup.target
to be reached before this was started.

Another change that we can probalby do is drop the before relationship
with the nss-lookup.target. That might just be implied with the current
version.

Changes:

https://1password.community/discussion/116663/1password-beta-0-9-2

Add update script