Implement UUID support in qrexec

[DemiMarie]

Open questions:

• How should dom0 be informed of the intended call target? Should it be SERVICE-NAME REMOTE-DOMAIN-NAME uuid UUID-OF-TARGET or SERVICE-NAME REMOTE-DOMAIN-NAME name @uuid:UUID-OF-TARGET?
• Should the target be informed of the source VM’s UUID? This allows race-free “boomerang” calls, but requires an API change.
• Probably more
  Fixes: Consider UUID syntax in qrexec policy qubes-issues#8510

[DemiMarie]

PipelineRetryFailed

[DemiMarie]

PipelineRetryFailed

[marmarek]

* [ ]  Should the target be informed of the source VM’s UUID?  This allows race-free “boomerang” calls, but requires an API change.

Definitely not instead of the name, as most(?) services needs actually the source name (things like subdir in QubesIncoming, or split-gpg prompt). As for extra data, its usefulness would also be limited (generally, the source qube is running during the connection, and the name cannot be changed while qube is running). And adding extra info to the protocol would be an API change anyway so needs to wait for R4.3.

[DemiMarie]

This version is quite a bit simpler than I thought, but it has no fallback to the name if the UUID symlink is not present, and doesn’t set up the UUID symlink itself. Therefore, it does not work.

Would it be possible to use an environment variable @marmarek? That could help avoid circular dependencies during upgrade. Of course, an alternative is to use snapshots to make the entire upgrade atomic, which is probably a better solution as so many things can fail.

[marmarek]

Forcing updating core-admin and core-qrexec at the same time via dependency is okay. There is no need to handle new qubesd starting old qrexec-daemon. Since it isn't necessary, I'd prefer to simply use a command line parameter for UUID, which is much cleaner than giving name via cmdline and UUID via environment.
And also, it's qrexec-daemon who should maintain the UUID symlink, since it maintain the other symlink already (again - consistency).
What might be useful (mostly for testing, as actual release upgrade needs reboot anyway) is to keep working with already running old qrexec-daemon - which basically means a fallback to name-based symlink.

[marmarek]

In addition to previous not addressed comments:

[marmarek]

pylint complains (minor thing)