Add Linux podman build to CI

[holly-cummins]

I've added a workflow to give us some coverage of podman on Linux. I've set it up to run on a schedule, rather than every PR or push.

Notes: In my first revision, I have the build triggering on PRs, so we can see it running. I'll remove those stanzas before merging. I do have a build which ran clean on my fork apart from permissions failures on the report upload.

I've been running this build on my own fork, and observed a number of failures. Most (all?) are not reproducible on local linux, and seem to be related to GitHub Actions virtualisation. I've disabled the tests in this PR, and raised issues. https://github.com/quarkusio/quarkus/issues?q=is%3Aissue+is%3Aopen+label%3Aenv%2Fpodman is the most convenient way to see a list of the issues (if you ignore ones raised by other people).

We're seeing issues building podman native, so I will also add some runs for that in a follow-on PR, but I wanted to get the JVM tests running first.

[quarkus-bot]

/cc @Sanne (hibernate-orm), @brunobat (micrometer), @ebullient (micrometer), @gsmet (hibernate-orm), @yrodiere (hibernate-orm)

[holly-cummins]

Oh rats, the report for my new workflow is still failing when run in the main build. I assumed it was just failing because I'd been testing in a fork.

 {"message":"Bad credentials","documentation_url":"https://docs.github.com/rest"}

I'll remove that step and we can work on figuring out why it's not working.

[holly-cummins]

I've removed the PR-trigger for the podman build, so the build of this PR should be very boring, but I believe this change is now ready to merge. We need native testing, but I will do that as a follow-on work item.

I've spoken with @gsmet, and we've agreed that the workflow file is rather large, which creates a maintenance burden. Longer term, it will be better to include podman in the regular matrix build. We don't want to exercise podman every PR, but we can do some tricks with the schedule and the matrix calculation. For example, if the schedule time matches a magic number, the matrix calculation will include podman. This scales better as we increase our podman coverage to mac, windows, etc. It means podman build results will be mixed in with the main CI results, which has advantages (one place to look, less clutter of workflows) and disadvantages (confusing if something fails).

The matrix calculation should be straightforward for JVM, and slightly harder for native, but we can get there.

Here's what a trigger-test might look like

on: 
  schedule: 
     - cron: '30 5 * * 1,3' 
     - cron: '30 5 * * 2,4' 
   jobs: 
      test_schedule: 
        runs-on: ubuntu-latest 
        steps: 
           - name: Not on Monday or Wednesday 
              if: github.event.schedule != '30 5 * * 1,3' 
              run: echo "This step will be skipped on Monday and Wednesday"

[gsmet]

@holly-cummins FWIW, you might be able to use github.event.schedule != '30 5 * * 1,3' in the global env: section of the job so you might be able to introduce a IS_PODMAN env var instead of using this test again and again. At least it's worth a try.