Load ProductID certificate metadata via pushsource [RHELDST-24276]

[MichalHaluza]

python-rhsm cannot be installed with GCC 14. Given that project has been deprecated for years, it's unlikely the actual underlying issue will be resolved. Pubtools-pulp uses python-rhsm to read ProductID certificates and pull product metadata from them. This commit leverages code for ProductID reading newly introduced in Pushsource instead of python-rhsm.

This MR also replaces rpm-py-installer with rpmdyn in the same fashion like it was done in release-engineering/pushsource@1c1b4f9

[MichalHaluza]

This MR depends on release-engineering/pushsource#476

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (5166766) to head (04a496e).

Additional details and impacted files

@@            Coverage Diff            @@
##            master      #284   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           57        57           
  Lines         3170      3168    -2     
=========================================
- Hits          3170      3168    -2     

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

[rohanpm]

Err... sorry to be pedantic again about this comment (but you have said in other reviews that you like it).

I don't think "mock" is the right word here, and I think using it contributes to confusion around what mocking is. Well, I don't think it's a very well-defined term, but I agree with Wikipedia's leading sentence: "A mock object is an object that imitates a production object in limited ways." You are providing real ProductId objects here, which are going to work in exactly the same way as ProductId objects loaded out of a cert. You're using the API of pushsource in a normal and valid way and I don't see how it should be considered "mocking". You're just providing your own data which skips the default behavior of trying to load that data from a file.

If I may give an analogy, if there was a function with a signature like:

def load_config(path: str = "/etc/some-default.cfg"):
    ...

...and some code were to call that function like cfg = load_config("my-non-default.cfg"), I don't think that should be called "mocking" the path or the config?

I believe it's better for the comment to say "we provide our own ProductIds", and also for us to think about the code in this way. Or if you wanted to emphasize that this is overriding the default method of obtaining the objects, you could even use the term "inject" per dependency injection, "a programming technique in which an object or function receives other objects or functions that it requires, as opposed to creating them internally".