fix(deps): keep child processes from inheriting listening sockets on Windows

CHANGELOG.md

@@ -10,6 +10,7 @@ Versions follow [Semantic Versioning](https://semver.org/).
 ## Unreleased
 
 ### Bug Fixes
+- **Windows: a tunnel can be restarted after setting up a key, instead of failing with the port still in use.** Setting up an SSH key runs `ssh-keygen`, and on Windows that child process inherited every socket OmnySSH had open at the moment it started, a tunnel's listening ports included. The ports then stayed taken for as long as the child lived, so stopping a tunnel and starting it again in that window failed with "Only one usage of each socket address is normally permitted", and because a tunnel that cannot bind is not retried, it stayed down until the app was restarted. A host whose tunnel starts with OmnySSH could also fail to come up at all when a key setup was running. The cause was in the event library underneath Tokio, which created sockets without asking Windows to keep them out of child processes; mio 1.2.1 sets `WSA_FLAG_NO_HANDLE_INHERIT` when it creates one, and this release moves to mio 1.2.3. Unix was never affected, since Tokio's sockets are close-on-exec there.
 - **Security: a server that offers a host key of another type than the one saved for it is refused.** OmnySSH compared the offered key only with saved keys of the same type. A host saved with its Ed25519 key that suddenly offered only an RSA or ECDSA key was therefore taken for a new host: the key was saved and the login went ahead, password included, and the dashboard did this in the background without anyone connecting. Someone intercepting the connection could get past the saved key this way. Like `ssh`, OmnySSH now refuses any key that matches none of those saved for the host, whatever its type, and says which type is saved. A server that really dropped the type of key it was saved with needs its old key removed once, as `ssh` also asks.
 - **A changed host key names its type and, on Windows, whose list held the old one.** OmnySSH 1.1.3 and earlier kept host keys in `%USERPROFILE%\ssh\known_hosts`, a list that PuTTY and OpenSSH never read. When a server was reinstalled, or a new one took over its address, OmnySSH refused it while PuTTY and PowerShell's `ssh` connected, and nothing said why they disagree. A refusal from that file now says it is the list OmnySSH kept up to 1.1.3. Every refusal also names the type of the key the server offered, ED25519, ECDSA or RSA, and the command that prints that key's fingerprint on the server: a server has one key of each type, and comparing the wrong one shows a mismatch that is not there.
 - **Servers from the RHEL/CentOS 6 era connect.** OpenSSH before 5.7 failed with "no common key exchange method". Its only key exchange without SHA-1 is diffie-hellman-group-exchange-sha256, which OmnySSH did not offer. Its only host keys are ssh-rsa and ssh-dss, and it predates the rsa-sha2 signatures, so an RSA key could not log in either. OmnySSH now offers diffie-hellman-group-exchange-sha256 and the ssh-rsa host key after every other method, so a server that supports anything newer negotiates exactly as before. An RSA key signs with SHA-1 only for a server that accepts nothing else: one that lists only ssh-rsa as the signatures it takes, or whose version, OpenSSH before 7.2 or Dropbear before 2020.79, predates that list, as PuTTY and `ssh` before 8.8 sign for it. SHA-1 key exchange, CBC ciphers and DSA keys are still left out.