ci(fuzzing): treat timeout as a successful workflow run

[alex-ter]

If we hit the fuzzing timeout, it means no crashes happenened, therefore it makes no sense to treat it as a workflow failure.

"timeout" returns an exit code 124 when this happens, and by default the Github runners treat non-zero ones as a failure.

Change the logic to convert the exit code 124 to 0 (success) and pass everything else (legitimate failures) through.

Tested via GH actions in my fork:

• Successful run (with a timeout)
• Unsuccessful run (with the fix for ci: fuzz run has been manually started #5140 applied, so it actually accidentally found something that crashed the tool!)

Closes #5244.

[alex-ter]

Rebased onto main to fix the mypy and black check failures.

[alex-ter]

The Linux test failure looks like something spurious, doesn't it? The same thing happens in my other PR #5257, but in the "3.10" check.

[...]
FAILED test/test_source_epss.py::TestSourceEPSS::test_parse_epss - sqlite3.OperationalError: database is locked
FAILED test/test_parsers.py::TestParsers::test_parser_env_test_0001 - sqlite3.OperationalError: database is locked
FAILED test/test_helper_script.py::TestHelperScript::test_parse_filename[libsndfile-1.0.25-12.el7.x86_64.rpm-libsndfile-1.0.25] - sqlite3.OperationalError: database is locked
[...]

[terriko]

This might be related to me having re-run the cache job and it maybe hadn't been finished before I started these tests. I'm going to re-run the failing ones and see. But I agree that it's not related to this PR.

[alex-ter]

Thank you. Passing now, could you please re-run those on #5257 too?