CI: Test liboqs integration

[mkannwischer]

mlkem-native has been integrated into liboqs (see #653).
We should test in our CI that future changes in mlkem-native do not break that integration.
The approach should be similar to what is done for AWS-LC (#654).
Here are the steps needed for liboqs:

• clone the main branch of liboqs (if this is too flaky, we can fix to the last release version)
• Patch the copy_from_upstream.yml with the new commit.
• Run the copy_from_upstream.py (that has some python dependencies)
• Run the liboqs build as per README
  • Once with cmake -DOQS_DIST_BUILD=ON -DOQS_OPT_TARGET=auto -DCMAKE_BUILD_TYPE=Release (C backend)
  • Once with cmake -DOQS_DIST_BUILD=OFF -DOQS_OPT_TARGET=auto -DCMAKE_BUILD_TYPE=Release (native backend - should do this on both x86 and AArch64)
• Run tests pytest -k ML-KEM

@bhess, does this make sense?

[bhess]

Hi @mkannwischer, I think such an integration test would be great!

This makes sense to me, just see the two comments below:

• Run the copy_from_upstream.py (that has some python dependencies)

You would have to run copy_from_upstream.py copy

• Once with cmake -DOQS_DIST_BUILD=ON -DOQS_OPT_TARGET=auto -DCMAKE_BUILD_TYPE=Release (C backend)

To test the C backend it should be cmake -DOQS_DIST_BUILD=OFF -DOQS_OPT_TARGET=generic -DCMAKE_BUILD_TYPE=Release. Otherwise, with OQS_DIST_BUILD=ON it would dynamically select the fastest implementation based on the cpu-flags.