try to keep libzstd.a "as is" once created

[Cyan4973]

to improve compatibility with parallel build scenarios such as make -j allmost.
Presumed to fix #2436

[terrelln]

Tests are failing

[Cyan4973]

All tests fixed.
Remaining ones are failing independently of this PR.
32-bit test is fixed in #2440.
Fuzzing + msan has been failing for a while now,
I may disable it on short term so that we stop considering "normal" to have red failures in CI.

[Cyan4973]

Actually, disabling fuzzing + msan seems more difficult than anticipated,
as it seems to be a runtime issue (time out),
but the script controllling all fuzzing jobs seems controlled from oss-fuzz :
https://github.com/facebook/zstd/blob/dev/.github/workflows/main.yml#L18 ,
so there is no obvious way to fix it, nor to opt out selectively from msan tests (but keep the rest running)
and I'm reluctant about removing all oss-fuzz tests on the ground that the msan variant is flackey.

[terrelln]

I'll open an issue on oss-fuzz about the msan failure.

[terrelln]

It looks like check-32bit test is failing, but that seems unrelated to this PR I think.

[terrelln]

google/oss-fuzz#4879

[evverx]

the script controllling all fuzzing jobs seems controlled from oss-fuzz :
https://github.com/facebook/zstd/blob/dev/.github/workflows/main.yml#L18 ,
so there is no obvious way to fix it, nor to opt out selectively from msan tests (but keep the rest running)
and I'm reluctant about removing all oss-fuzz tests on the ground that the msan variant is flackey.

I think it should be possible to remove "memory" from the "sanitizer" list to turn off only Msan there:

diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index 0e14345..5e5aae1 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -6,7 +6,7 @@ jobs:
     strategy:
       fail-fast: false
       matrix:
-        sanitizer: [address, undefined, memory]
+        sanitizer: [address, undefined]
     steps:
     - name: Build Fuzzers (${{ matrix.sanitizer }})
       id: build

Though I hope the issue will be fixed soon.

[Cyan4973]

That's a good point @evverx ,
we should probably do that while waiting for the issue to get fixed on ossfuzz side.