Update CI container to Fedora-38

[webbnh]

Now that Fedora-36 has reached end-of-life, we need to update the default container image used by the CI and jenkins/run to F38.

However, initial attempts at this proved to be problematic. So, this PR contains two sets of changes:

• a change to the jenkins/Makefile to switch the base image for the CI container from F36 to F38; and
• a pair of changes to restrict the legacy Agent testing on Python 3.6 to use older versions of certain packages.

The version restriction has basically no effect under F36, so this PR can be merged without adverse affects. Once it has been merged, I'll build and push a new version of the CI container, switching it from the F36 base to the F38 base -- this will break all main-branch CI builds which haven't yet been rebased on this PR.

PBENCH-1161

[dbutenhof]

This is actually interesting since I don't think the CI is in any way testing this change, right?

[webbnh]

Once I'm satisfied with this change (note that this PR is currently a "draft"), I will use it to build and push an image (which I will sanity check locally), and then I'll make it "live", at which point the CI will start using it for everything...and, if nothing falls over, I'll consider that a successful test. (Think "Ghostbusters" here....)

But, you are correct, there is no CI testing of the building of the container image used by the CI (et al.)...which is probably OK, since we don't normally build this image -- we just use it. If we had infinite resources, then, yeah, it would be appropriate to rebuild it at intervals (just to prove that we can), but I don't think it is unreasonable to defer the detection of problems to the point where we actually need to address them. (E.g., we don't need yet another point of failure in our "normal" CI runs.)

[webbnh]

So, the "test" was not successful. (For some reason, on F38, Mr. Jenkins decides to install a new version of python-daemon rather than using the system-supplied one, and the new one, because of its dependency on a newish setuptools, is not compatible with Python 3.6, which means that we cannot run the Agent legacy tests, and the build fails.)

So, I'm returning this PR to "draft" status until we can devise a way around this conundrum.

[webbnh]

This change is now ready for review. Thanks!

[dbutenhof]

"Contraints" vs "requirements" ... interesting distinction of which I was previously unaware.

[webbnh]

"Contraints" vs "requirements" ... interesting distinction of which I was previously unaware.

As was I. However, the modern Pip objects if you have more than one requirement for the same package...even if the requirements are compatible! So, I was happy to learn of the support for constraints. (And, once you get into it, separating the constraints from the requirements makes very good sense.)