Adjust pgAdmin version comparision logic

[tjmoore4]

Checklist:

• Have you added an explanation of what your changes do and why you'd like them to be included?
• Have you updated or added documentation for the change, as applicable?
• Have you tested your changes on all related environments with successful results, as applicable?
  • Have you added automated tests?

Type of Changes:

• New feature
• Bug fix
• Documentation
• Testing enhancement
• Other

What is the current behavior (link to any open issues here)?
Now that the current version of pgAdmin is greater than 9.9, the version comparison logic has to be updated to properly compare the values (i.e. we can no longer use a simple x < y to compare floats).

What is the new behavior (if this is a feature change)?

• Breaking change (fix or feature that would cause existing functionality to change)
  This update makes the necessary adjustments so our code works as expected for newer versions of pgAdmin.

Other Information:
Issue: PGO-2838

[dsessler7]

I imagine that the idiomatic way to do this in go would be to use the following package:
https://pkg.go.dev/golang.org/x/mod/semver

But I'm fine with what you've done here. LGTM.

[tjmoore4]

I imagine that the idiomatic way to do this in go would be to use the following package: https://pkg.go.dev/golang.org/x/mod/semver

But I'm fine with what you've done here. LGTM.

🤔 If I understand correctly, I think that package requires the version string to begin with a v? The current string is stored in the status without one, for example "9.11". In any case, hopefully this will be robust enough without requiring a new import.

[dsessler7]

I imagine that the idiomatic way to do this in go would be to use the following package: https://pkg.go.dev/golang.org/x/mod/semver
But I'm fine with what you've done here. LGTM.

🤔 If I understand correctly, I think that package requires the version string to begin with a v? The current string is stored in the status without one, for example "9.11". In any case, hopefully this will be robust enough without requiring a new import.

Yeah, I'd just slap a "v" on the front... But again, I think what you've got here is fine.