Improve handling of hostkey errors in provisioner

[Ma27]

While recreating a devhost that was garbage-collected in the meantime with batou I got the following logs:

[...]
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:lD0JR5kMvsJn3ZeDKVAzQa2dS6HXs9tkR9IX4gx6L3M.
Please contact your system administrator.
Add correct host key in /Users/ma27/.batou/known_hosts to get rid of this message.
Offending ED25519 key in /Users/ma27/.batou/known_hosts:4
Password authentication is disabled to avoid man-in-the-middle attacks.
Keyboard-interactive authentication is disabled to avoid man-in-the-middle attacks.
============================================================= Deploying =============================================================
38ef16df: Scheduling component sshkeypair ...
[...]

This seemed a little alarming to me given that batou just seems to continue after encountering a hostkey mismatch.

The behavior seems to be caused by the following line: https://github.com/flyingcircusio/batou/blob/main/src/batou/provision.py#L71

• I've seen provisioners run on each deploy (e.g. devhost provisioners applying NixOS config). Hence, I think that the only valid case where host-key checking is allowed to fail is if a devhost (or VM) got purged and a new one has been created on same IP or hostname (causing the hostkey error). In any other case the hostkey checking should remain active.
• When the above case happens, batou should explicitly communicate why it's continueing despite the hostkey error so that I don't have to check whether I found a security issue by accident.