refactor(gui-client): use existing IPC framework for deeplinks (#9047)

We already have a pretty powerful IPC framework in place to communicate
between the GUI and the service process. The deeplink implemenation uses
the same IPC mechanisms (UDS / pipes), yet it is effectively a
re-implementation of what we already have, just with less functionality.

In order to provide a more sophisticated handling of the case where
Firezone is launched again while it is already running, we refactor the
deeplink module to reuse the existing IPC framework. This makes it quite
easy to then reuse this in order to ping the already running Firezone
process that a new instance was launched.

For now, this doesn't do anything other than writing a log entry. This
however lays enough ground-work for us to then implement a more
sophisticated handling of that case in the future, e.g. open new windows
etc.

One caveat here is that we are now trying to connect to an existing IPC
socket on every startup, even the first one. Our IPC code has a retry
loop of 10 iterations to be more resilient on Windows when connecting to
pipes. Without any further changes, this would now delay the start of
Firezone always by 1s because we would try to connect to the socket 10x
before concluding that we are the first instance. To fix this, we make
the number of attempts configurable and set it to 1 when attempting to
the GUI IPC socket to avoid unnecessary delays in starting up the
Client.

Related: #5143.

scripts/tests/linux-group.sh

@@ -8,7 +8,7 @@ source "./scripts/tests/lib.sh"
 BINARY_NAME=firezone-client-ipc
 FZ_GROUP="firezone-client"
 SERVICE_NAME=firezone-client-ipc
-SOCKET=/run/dev.firezone.client/ipc.sock
+SOCKET=/run/dev.firezone.client/tunnel.sock
 export RUST_LOG=info
 
 cd rust || exit 1