Fix the image tag

[ndokos]

Fixes #3445

pbench_demo uses an image downloaded from Quay.io. It assumes that the image will contain pbench-generate-token which is available currently but it is deprecated and will not be available in the future. In particular, the specified image
quay.io/pbench/pbench-agent-all-fedora-36:main does not contain the script. We need to make use of
quay.io/pbench/pbench-agent-all-fedora-36:b0.72 instead.

PBENCH-1129

[dbutenhof]

OK so far as it goes, however I almost wonder if the b0.72 branch demo script should be oriented towards the 0.69 id_rsa-based pbench-move-results instead of using a token. We don't exactly disallow creating a b0.72 server user or authenticating against it, but the "normal" and advertised mode of interacting with b0.72 is through the 0.69-11 passthrough server and the standard legacy user.

Ah, well; it's a contrib so I'm not objecting so much as wondering why we'd care? I think we should be testing Pbench Agent 0.72 against the 0.69-11 passthrough and against the 1.0 staging server, neither of which have any use for pbench-generate-token. 😁

[webbnh]

I feel like this solution is the least of various evils. Part of the power of this approach is that the pbench script stands by itself, without requiring a Git checkout and requiring only minimal configuration (and the demo script builds on that).

• Dave's point is excellent, but it would require getting the SSH key somehow and making it available inside the container, which is arguably somewhat more than "minimal configuration".
• Another option would be to use the contents of jenkins/branch.name for the tag (under the assumption that it is correct 😲), but that would require a Git checkout....

In the end, the pbench_demo file is really supposed to be a "list of commands you might want to run" as opposed to an actual script, so the contents of those lines are really up to the user, and specifying the appropriate container image tag would be a personal choice. 🙃