[Feature]: Store user SSH key on the server

[peterschmidt85]

Fixes #2053

• This PR introduces two new properties to the user model: ssh_private_key and ssh_public_key. These properties are automatically assigned when users are created or when a user submits a run without specifying a public key.
• When a run is submitted without a specified public key, dstack automatically assigns it to the run spec model from the user model.
• The public key is now optional in the run spec. However, it is assigned during server validation if it is empty. This ensures the public key in the run spec in the database is always set.
• The attachment logic now checks the run’s public key and attempts to use the user’s private key if it matches. Otherwise, it falls back to the legacy local SSH key.

Warning

The CLI still assigns the public key from the legacy local SSH key. However, if a run was submitted without an SSH key (for example, via the API and automatically assigned the user’s public key), the new CLI will be able to attach to it using the user’s key.

Backward compatibility:

• The new CLI (>=0.19.33) works with old servers (<0.19.33).
• The old CLI (<0.19.33) works with new servers (>=0.19.33).
• The new CLI (>=0.19.33) can attach to runs submitted by old servers (<0.19.33).

Warning

Since 0.19.40, the client will stop using the legacy local SSH key and will require that all users have updated their servers to at least 0.19.33.

[jvstme]

Is the user supposed to do anything when they see this warning? If not, the warning is unnecessary and will probably only confuse the user, since they typically don't think about what keys dstack uses internally

[peterschmidt85]

Decided to keep the warning for now, but we can remove it in a separate PR once we’ve dogfooded it more.

[jvstme]

I think seeing it on every apply and attach and not being able to do anything about it will be a bit annoying. Anyways, it's up to you