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.587% (+0.002%) from 83.585%
when pulling db482a6 on gyx-2279-remove-git-tracked-acvp-test-vec
into 97f6b86 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.

[xuganyu96]

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

The test vectors are hosted on GitHub, not NIST server. I am open to discuss backup solutions, but for now I consider the cost of maintaining local copies of test vector to significantly outweigh the risk of test vectors becoming unavailable.

[xuganyu96]

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

The test vector JSON files are currently hosted on GitHub, not NIST website. It is true that GitHub might go down, but I think that this risk is insignificant, especially since if GitHub goes down, GitHub Actions will likely go down, in which case we are running into much bigger problems than a few ACVP test vectors being offline.

cc: @ashman-p @baentsch @dstebila

[ashman-p]

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

The test vector JSON files are currently hosted on GitHub, not NIST website. It is true that GitHub might go down, but I think that this risk is insignificant, especially since if GitHub goes down, GitHub Actions will likely go down, in which case we are running into much bigger problems than a few ACVP test vectors being offline.

cc: @ashman-p @baentsch @dstebila

Thanks, Bruce. I understand now. I have no further issues with this.