we need to send a file descriptor to the net process when we use a custom client certificate. Don't know how I missed it...

I'd like to use execlp() in the near future, which means that unveil needs to be disabled. It's already virtually disabled, since we can shell out to execute stuff, so it's not a great loss. This will be improved in the future once the "core" process will be split off the UI.

At the moment telescope loads a mapping host:port/path -> certificate from a file and always uses it, no ways to change it, use a temporary one, generate a new one, etc are provided yet. The format of ~/.telescope/certs/certs is host port path certificate file name where the certificate file name is the name of a file inside ~/.telescope/certs. ~/.telescope/certs/ is ~/.local/share/telescope/ when using XDG.

can conflict with sys/prctl.h, spotted while trying to build on alpine linux.

The previous separation between the fs and ui process wasn't that good. The idea was to have a `ui' process tightly sandboxed, but it was a lie actually. `ui' was one imsg away from making internet connections and accessing data on the disk, so it wasn't really limited in (almost) any way. Furthermore, having to serialize data to/from the fs proc started to become not really maneagable. As a first step to fix this situation, join the fs and ui process.

if telescope is started with an url while there is already another instance of it running and the -S flag is not provided, the link will be automagically opened into the running instance of telescope. Telescope now listens on a UNIX domain socket in ~/.telescope/ctl (or ~/.cache/telescope/ctl if XDG is used) for commands.

cf. gmid 1.8.1 and recent changes in game of trees. This doesn't warrant an immediate release since every action is limited to /tmp, ~/Downloads and {config,data,cache}_home.

landlock is applied only to the ui process to drop fs access and in the fs process to limit where telescope can read/write files. The network process is more difficult to landlock because while in theory it doesn't need *any* fs access, in practice it needs to read (at least) files inside /etc/ for DNS to work.

it's good for thing like images and text with weird encodings.

now that we have a bounch of -Wxxx flags during compilation, let's fix everything.