Remove ACVP test vectors from repository

[xuganyu96]

This PR closes #2279

ACVP test vectors will now be fetched from https://raw.githubusercontent.com/usnistgov/ACVP-Server/refs/tags/v1.1.0.40/gen-val/json-files/ at test time using Python's requests library. Previously stored JSON files and fetch_values.sh scripts were removed. I also ran a Python code formatter.

Some considerations for reviewers:

• Speaking from principles, external resources (i.e. the JSON file) should be set up as pytest.fixture so that a single instance of a resource is not fetched repeatedly across tests. However, from past experience I found fixtures to be a pain to debug, and all but one JSON file is used exactly once, so I chose to not use fixtures
• Currently the JSON files are fetched from the website instead of GitHub API. Should this be a concern?

• [NO] Does this PR change the input/output behaviour of a cryptographic algorithm (i.e., does it change known answer test values)? (If so, a version bump will be required from x.y.z to x.(y+1).0.)
• [NO] Does this PR change the list of algorithms available -- either adding, removing, or renaming? Does this PR otherwise change an API? (If so, PRs in fully supported downstream projects dependent on these, i.e., oqs-provider will also need to be ready for review and merge by the time this is merged. Also, make sure to update the list of algorithms in the continuous benchmarking files: .github/workflows/kem-bench.yml and sig-bench.yml)

[coveralls]

coverage: 83.601% (+0.01%) from 83.589%
when pulling 9de3977 on gyx-2279-remove-git-tracked-acvp-test-vec
into ed5c2cc on main.

[baentsch]

From just looking at the code, this seems OK to me. Thanks @xuganyu96 !

I chose to not use fixtures

Sounds sensible to me.

Currently the JSON files are fetched from the website instead of GitHub API. Should this be a concern?

My only concern would have been that that website may be unreachable when CI runs -- but given this is also on GH and not some US gov server (that may be subject to shutdown (in various meanings of the word :), I'd say it's highly unlikely for this to be a problem. My take for now: Let's see how this performs and whether we need to improve later (eg, using GH caching).

[ashman-p]

I also share @baentsch concerns about NIST server accessibility. It adds another variable to trouble shoot in case of a test failure.