Implement and document compatibility with HPS releases

[FedericoNegri]

• Implement mechanism to check requirements on service versions, following pyansys guidelines
• Document product compatibility
  
• Clean up data transfer client exposure in the main PyHPS client

[codecov]

Codecov Report

Attention: Patch coverage is 95.93496% with 5 lines in your changes missing coverage. Please review.

Project coverage is 87.58%. Comparing base (2084b1c) to head (c75c877).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/ansys/hps/client/client.py	82.35%	3 Missing ⚠️
src/ansys/hps/client/check_version.py	98.00%	1 Missing ⚠️
src/ansys/hps/client/exceptions.py	66.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #559      +/-   ##
==========================================
+ Coverage   87.21%   87.58%   +0.36%     
==========================================
  Files          64       65       +1     
  Lines        2840     2900      +60     
==========================================
+ Hits         2477     2540      +63     
+ Misses        363      360       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ojkoenig]

Looked at the PR, two comments:

1. Do we need to do that magic with static dicts to map from HPS version to JMS/RMS version? This adds another place where new versions will need to be added manually as we create new, and I guess what we want to do is check against global HPS version?
   Is the reason that you cannot query hps version easily?

2. For RMS you seem to add version check functionality but not using it? Or did I miss something?

[FedericoNegri]

Looked at the PR, two comments:

1. Do we need to do that magic with static dicts to map from HPS version to JMS/RMS version? This adds another place where new versions will need to be added manually as we create new, and I guess what we want to do is check against global HPS version?
   Is the reason that you cannot query hps version easily?
2. For RMS you seem to add version check functionality but not using it? Or did I miss something?

@ojkoenig

1. I'd love to just query the release version. As far as I'm aware, there's no service publishing that info. Not surprisingly, since we talk about the need for a service registry since ever.
   In any case, I don't see where's the "magic" It's a simple dictionary lookup...

2. In the RmsApi I've only added the version property. And in check_version I've included the RMS versions: given the time it took me to figure out the JMS ones, I didn't want to do it again in the future. But you're right that I didn't add yet version requirements on RMS calls (some would be appropriate for HPS 1.1.1, but didn't get to that yet).

[ojkoenig]

1. I'd love to just query the release version. As far as I'm aware, there's no service publishing that info. Not surprisingly, since we talk about the need for a service registry since ever.
   In any case, I don't see where's the "magic" It's a simple dictionary lookup...

I agree that service registry would be the place where HPS version could be queried, once we have one.
So will approve the PR for now so that you can move on.
Not much magic you are right, but another place where hardcoded versions are manually added...

2. In the RmsApi I've only added the version property. And in check_version I've included the RMS versions: given the time it took me to figure out the JMS ones, I didn't want to do it again in the future. But you're right that I didn't add yet version requirements on RMS calls (some would be appropriate for HPS 1.1.1, but didn't get to that yet).

ok

[ojkoenig]

Answered your last comments