[CLI Improvements] validate that server and CLI version match

[schoren]

When running any cli command that communicates with a server, we want to make sure that they are both speaking the same version, to avoid unexpected behaviors.

[xoscar]

@schoren when a version mismatch happens, what do we need to do? what is the goal for users to do after they find out there is a version mismatch?

[schoren]

Probably a question for @kdhamric and @olha23. We talked about not allowing to run commands if version don’t match, but we didn’t go into more details

[olha23]

@schoren @xoscar When a version mismatch happens between the CLI and the server, the goal is to prompt the user to update the CLI to match the server version. User should be informed of the version mismatch and be provided with instructions on how to update the CLI to match the server version. This can be done through a clear error message, along with instructions or a link to documentation on how to update the CLI.

[xoscar]

Team, by going through this issue I found a couple of things we might need to consider:

1. What happens if the server is behind the CLI? Should we prompt an error message?
2. If we want to enforce that the server and CLI versions match, we'll have to trigger a request to get the server version before executing any command/verb. Is this what we want?

[schoren]

1. I think we defined a first iteration where ANY kind of version missmatch triggers a message on the CLI side prompting users to upgrade.
2. If I remember correctly we already talked about having the server either exposing a /version (or similar) endpoint. I think we can also consider addding an X-Tracetest-Version header in all responses, so that there's no need for a special request to validate the response. On any request made by the CLI, it can compare the versions.

[kdhamric]

@schoren response sound good to me