Move and rename SSH master socket path to avoid path length limit

[happz]

Putting SSH sockets into plan directory is nice and all, no chance to
re-use socket by mistake, no conflicts, but it turns out SSH will not
accept path longer than 104 characters. Or 108, depending who you ask.

So, moving sockets once again, this time then live in run workdir,
they no longer contain plan name, because that can be very long, and we
have two fallbacks:

• if the path is too long, we use hashlib and create less readable,
  but hopefully shorter name, and
• if the path is still too long, SSH multiplexing is disabled
  completely.

Pull Request Checklist

• implement the feature
• extend the test coverage

[happz]

/packit test

[martinhoyer]

Well if there is a ssh problem with ssh-socket path again with this, there really is something cursed.

[seberm]

If this is going to be a bugfix release tmt-1.36.1, you should probably describe the changes in the release notes (releases.rst).

[happz]

If this is going to be a bugfix release tmt-1.36.1, you should probably describe the changes in the release notes (releases.rst).

Hmm, I think it does deserve a release note, but for 1.37 - I would expect release notes for 1.36.1 to be constructed in commit(s) creating 1.36.1 out of 1.36.0 tag, I suppose some cherry-picking of needed bugfixes + a commit with release stuff.

Edit: added in 4653adc

[psss]

Changes look good, just noticed one test nitpick. However, I'm not sure that the master ssh connection actuallly works. Tested with a simple tmt init -t mini && tmt run and it seems that it takes about one second to execute each ssh command:

15:14:38   Run command: ssh ... -S/var/tmp/tmt/run-017/ssh-sockets/127.0.0.1-10022-root.socket ... cat /etc/os-release'
15:14:39   Run command: ssh ... -S/var/tmp/tmt/run-017/ssh-sockets/127.0.0.1-10022-root.socket ... cat /etc/lsb-release'
15:14:39   Run command: ssh ... -S/var/tmp/tmt/run-017/ssh-sockets/127.0.0.1-10022-root.socket ... arch'
15:14:40   Run command: ssh ... -S/var/tmp/tmt/run-017/ssh-sockets/127.0.0.1-10022-root.socket ... uname -r'
15:14:42   Run command: ssh ... -S/var/tmp/tmt/run-017/ssh-sockets/127.0.0.1-10022-root.socket ... apk --version'
15:14:43   Run command: ssh ... -S/var/tmp/tmt/run-017/ssh-sockets/127.0.0.1-10022-root.socket ... apt --version'
15:14:44   Run command: ssh ... -S/var/tmp/tmt/run-017/ssh-sockets/127.0.0.1-10022-root.socket ... /bin/bash -c '"'"'
15:14:45   Run command: ssh ... -S/var/tmp/tmt/run-017/ssh-sockets/127.0.0.1-10022-root.socket ... dnf5 --version'
15:14:46   Run command: ssh ... -S/var/tmp/tmt/run-017/ssh-sockets/127.0.0.1-10022-root.socket ... /bin/bash -c '"'"'
15:14:47   Run command: ssh ... -S/var/tmp/tmt/run-017/ssh-sockets/127.0.0.1-10022-root.socket ... stat /run/ostree-booted'
15:14:48   Run command: ssh ... -S/var/tmp/tmt/run-017/ssh-sockets/127.0.0.1-10022-root.socket ... cat /proc/filesystems'

Shouldn't these simple commands run much faster? What would be an easy check to ensure that the master connection was actually used? Anyway, I have a feeling that the problem is there for some time already (not caused by this patch). But I'd say it would be good to get it fixed anyway.

[psss]

So the problem was caused by trying to spawn the master ssh connection before the guest was ready. We need to check that guest is up before creating the master socket. To be addressed in a separate pull request.

[psss]

Forgot to mention: @happz, I really love your special branch names, like this one ;-)

[happz]

/packit test

[happz]

/packit test

[happz]

/packit test

[psss]

Failing test is an irrelevant dhclient avc error, everythin else green, merging.