feat: Resolve release version from new /version endpoint.

[bdferris-v2]

Per discussion in #1520, we'd like to pull the current release version of the app from the new /version endpoint.

Please make sure these boxes are checked before submitting your pull request - thanks!

• Run the unit tests with gradle test to make sure you didn't break anything
• Format the title like "feat: [new feature short description]". Title must follow the Conventional Commit Specification(https://www.conventionalcommits.org/en/v1.0.0/).
• Linked all relevant issues
• Include screenshot(s) showing how this pull request works and fixes the issue(s)

[jcpitre]

@bdferris-v2 I'm a bit late to the party on this one.
If I understand correctly we want to call a version endpoint so we can count how many times the software is used?
With the ultimate goal of deprecating the desktop GUI version if we realize it's not really used.
I did not see how we distinguish between runs of the CLI version, the GUI version and the Web version.
Also will the runs of the app done during development be counted also?

[github-actions]

✅ Rule acceptance tests passed.
New Errors: 0 out of 1472 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
Dropped Errors: 0 out of 1472 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
New Warnings: 0 out of 1472 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
Dropped Warnings: 0 out of 1472 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
0 out of 1472 sources (~0 %) are corrupted.
Commit: d7021c1
Download the full acceptance test report here (report will disappear after 90 days).
✅ Rule acceptance tests passed.

[bdferris-v2]

@jcpitre that's a great point. Technically, the web validator doesn't check for the latest release version, so it wouldn't be counted here. But it's reasonable to want to distinguish between CLI and Desktop App traffic. It's also reasonable to distinguish between development vs prod traffic.

To that end, I've add two parameters to the /version api call:

• application_type: an enum that will be CLI, DESKTOP, or WEB based on the application
• current_version: the current application version. Will have a -SNAPSHOT suffix for dev builds.

I've also verified with @davidgamez that it's possible to see these parameters in the logs.

I think that should be sufficient to distinguish between the various type of traffic. Thoughts?

[github-actions]

✅ Rule acceptance tests passed.
New Errors: 0 out of 1472 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
Dropped Errors: 0 out of 1472 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
New Warnings: 0 out of 1472 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
Dropped Warnings: 0 out of 1472 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
0 out of 1472 sources (~0 %) are corrupted.
Commit: 6beb991
Download the full acceptance test report here (report will disappear after 90 days).
✅ Rule acceptance tests passed.

[jcpitre]

LGTM