Ensure generic OQS_OPT_TARGET in weekly CT tests

[SWilson4]

Set -DOQS_DIST_BUILD=OFF in the "generic" weekly constant-time test run so that the OQS_OPT_TARGET variable has an effect. This currently isn't being done, which means that only the AVX2 versions are being tested (in the weekly "extensions" run). As mentioned in #1617.

• 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.)
• 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 and OQS-OpenSSH will also need to be ready for review and merge by the time this is merged.)

[baentsch]

Conceptually I agree that we should test the generic/reference/C code for CT, so this PR makes sense. But I wonder whether it should be extended to also (keep) testing the optimized code? It's running most of the time (as say AVX2 is available in most machines these days). See #1619 as a possible next step.

[SWilson4]

Conceptually I agree that we should test the generic/reference/C code for CT, so this PR makes sense. But I wonder whether it should be extended to also (keep) testing the optimized code? It's running most of the time (as say AVX2 is available in most machines these days). See #1619 as a possible next step.

The optimized code will still be tested via the extensions job (I think). Right now we have two jobs running the AVX2 code; this change should make it so that one runs the "pure" C code and the other runs the code with extensions.

[baentsch]

The optimized code will still be tested via the extensions job (I think)

Ah, Yes. Completely overlooked that one. Indeed "haswell" has the relevant extensions. Thanks (for PR & explanation)!

[baentsch]

@dstebila Weekly runs are on Friday, so approval & merge before would be great. Alternatively, shall we exclude such "infrastructure" PRs from the "2 approvals needed" rule?

[dstebila]

@dstebila Weekly runs are on Friday, so approval & merge before would be great. Alternatively, shall we exclude such "infrastructure" PRs from the "2 approvals needed" rule?

I don't know how to change the "2 approvals needed" rule to only apply to certain directories -- we can apply it only to certain branches, but I don't see directories as an option.

[baentsch]

I don't know how to change the "2 approvals needed" rule to only apply to certain directories -- we can apply it only to certain branches, but I don't see directories as an option.

Hmm -- just read the documentation and I also didn't find a way how to do that. A bit disappointing, I'd say. But what I did find is an option that demands approval by code owners. And that can be set to specific directories, right? So what about the idea to carefully define code ownership(s), set this flag and revert back to just 1 review needed for PRs? Not ideal if there's a sole code owner designated for some sections and that person isn't around -- in such case the 4 eyes rule would be better again...

[SWilson4]

I've preserved @baentsch's suggestion in #1623 in case we want to continue discussion somewhere active after this is merged.