fix(connlib): increase WireGuard max rekey time (#12560)

In order to migrate an existing tunnel to a new candidate pair without
performing a full reset, our re-key attempt time must be greater than
our ICE timeout.

---------

Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

fix(connlib): increase WireGuard max rekey time (#12560)

In order to migrate an existing tunnel to a new candidate pair without
performing a full reset, our re-key attempt time must be greater than
our ICE timeout.

---------

Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

fix(connlib): increase WireGuard max rekey time (#12560)

In order to migrate an existing tunnel to a new candidate pair without
performing a full reset, our re-key attempt time must be greater than
our ICE timeout.

---------

Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

fix(connlib): increase WireGuard max rekey time (#12560)

In order to migrate an existing tunnel to a new candidate pair without
performing a full reset, our re-key attempt time must be greater than
our ICE timeout.

---------

Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

fix(connlib): increase WireGuard max rekey time (#12560)

In order to migrate an existing tunnel to a new candidate pair without
performing a full reset, our re-key attempt time must be greater than
our ICE timeout.

---------

Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

fix(gui-client): set initial system resolvers on tunnel (#11984)

In #11694, we refactored the DNS resolution of the portal's hostname to
be fully independent of the `libc` APIs by always explicitly sending UDP
DNS queries instead via a routing-loop protected socket. To ensure the
initial connection attempt to the portal is successful, we are now also
passing the system resolvers via the constructor of `Tunnel` instead of
calling `set_dns` directly after.

Due to the differences in how the various platforms monitor the system
resolvers, this created a bug in the GUI client where we missed to set
the initial system resolvers also on the tunnel. As a result, DNS
resources would not work until we processed at least 1 change event from
the system DNS notifier task.

Luckily, this only affects the Linux GUI client, which has not been
released yet since #11694:

- The macOS and Android clients still rely on the initial `set_dns` call
to initialize the resolvers.
- The headless client does not proactively watch for system resolver
changes and instead reads and sets them on an interval.
- The Windows client appears to trigger a call to `set_dns` during
startup, also masking the problem.

fix: only set routes of supported IP stack (#11930)

Righ now, we always attempt to set all routes on the system, regardless
of what IP stack is supported on the TUN device. This works because
internally, we don't fail when adding a route but only log it as a
warning and keep going. Additionally, we do check for certain error
codes like `EEXIST` to not unnecessarily spam Sentry with warnings.

As another defense-in-depth measure, we unify the `set_routes` API and
only pass those routes that are supported by the TUN device's IP stack.

fix(portal): Update directory sync error handling (#11884)

Mostly updates around Okta directory sync error handling / edge cases.

fix(apple): reliably read system resolvers (#11735)

In all Firezone clients we have a split DNS feature that forwards
matched queries through Firezone while leaving unmatched queries to go
to either:

1. The system's default DNS resolvers, typically set by DHCP on the
system's local network
2. An admin-configured upstream resolver override

On macOS, we can read these via the
[`SystemConfiguration`](https://developer.apple.com/documentation/systemconfiguration)
framework, which exposes an interface for making a call to the `configd`
process over XPC in order to read the resolvers scoped to the system's
primary interface.

On iOS, the `SystemConfiguration` framework is unavailable, however, we
can achieve the same result by finding the symbol for the
`dns_configuration_copy` function and calling it manually.

Both of these approaches are combined into a single
`SystemConfigurationResolvers` interface consistent between the two
platforms.

Resolves #11192 
Fixes #10811

---------

Co-authored-by: Thomas Eizinger <thomas@eizinger.io>

fix(connlib): resolve with system resolvers if no dns servers (#11626)

When connecting to the portal, we were using whatever resolvers were
last configured via the `setDns` command, initializing to the empty list
`[]`. There were three related edge case issues here:

- If we ever failed to connect the portal on the first attempt,
subsequent attempts would not resolve the portal and fail with socket
errors
- If we get a network reset before the first `setDns` command,
reconnecting to the portal will fail repeatedly (see
https://github.com/firezone/firezone/actions/runs/20695702337/job/59410655664)
- If these somehow ever get set to `[]` (such as if there is a bug in
the portal or misconfiguration in the portal that sends an empty list),
reconnecting to the portal will never succeed

To make connecting to the portal more resilient, we update the udp
resolver to fallback to system resolver resolution if there are no
resolvers set.