ci: update step-security/harden-runner and update allowed endpoints

[varunsh-coder]

This PR does two things:

1. Updates step-security/harden-runner from 2.5.0 to 2.5.1 in the GitHub Actions workflows.

   GitHub Actions recently started making outbound calls to a few endpoints not in the default allowed list. This causes the build to get stuck when using a block policy with harden-runner. This update to harden-runner (version v2.5.1), adds these new endpoints to the default allowed list.

   I noticed that some of the workflows in this repository are getting stuck, so creating a PR to bump up the version to the latest.

   Release notes for the latest version are here:
   https://github.com/step-security/harden-runner/releases/tag/v2.5.1

2. I also noticed while testing the workflows that some endpoints that should be allowed were not in the allowed list, and were getting blocked, so added them to the allowed list.

[kmk3]

@varunsh-coder

Merged, thank you for all the fixes!

Note: I squashed the "Update allowed endpoints" commits and rebased to master
to include the following commit (to fix one CI check):
2300980

Cc: @topimiettinen

[glitsj16]

@varunsh-coder @kmk3 @topimiettinen

While you guys are on the topic of Firejail's CI, here's a FYI. The mold linker offers a GitHub Action called setup-mold.

Quoting from mold's [how-to]:

You can use our setup-mold GitHub Action to speed up GitHub-hosted continuous builds. Although GitHub Actions run on a two-core machine, mold is still significantly faster than the default GNU linker, especially when linking large programs.

Might be worthwhile to check it out...

[kmk3]

While you guys are on the topic of Firejail's CI, here's a FYI. The mold
linker offers a GitHub Action called
setup-mold.

Quoting from mold's [how-to]:

You can use our setup-mold GitHub Action to speed up GitHub-hosted continuous
builds. Although GitHub Actions run on a two-core machine, mold is still
significantly faster than the default GNU linker, especially when linking
large programs.

Might be worthwhile to check it out...

Nice, it might save a few seconds when building locally and it could be useful
to check for portability issues.

But note that linking does not take a significant amount of time in CI overall,
as firejail is not a very large program.

Most of the slowness from CI builds is due to make being executed
sequentially. Some jobs could be executed in parallel, though I'd keep at
least the main build one sequential, as parallel jobs are harder to debug.

The build_and_test is the job that takes the most time, though most of the
slowness there comes from the tests, as they are now all executed sequentially
in the same job (and also likely due to them using a lot of sleep commands).