Suppression file update after ppc64le constant-time check

[bhess]

Minor suppression file updates after a constant-time check on ppc64le (see #1037):

• Dilithium: (i) two line numbers changed, (ii) using explicit function name (fun:rej_uniform) for generic Dilithium
• Adds the new BIKE variants (adding to issues.json like the previous variants, expert review might be needed here)

The CI log with BIKE and Dilithium reports is available here: ppc64le.txt
The SPHINCS+ reports are documented separately in #1038.

The reported issues (except #1038) should also be reproducible using the constant-time-x64-extensions / constant-time-x64 circleci jobs. After this fix, all constant-time checks pass on x86_64 / ppc64le. BIKE will have to be added separately after this PR.

• [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 the list of algorithms available -- either adding, removing, or renaming? (If so, PRs in OQS-OpenSSL, OQS-BoringSSL, and OQS-OpenSSH will also be required by the time this is merged.)

[jschanck]

The new BIKE code has some non-constant time subroutines for some platforms, but there's definitely an attempt to be constant time on recent Intel CPUs. It will take quite a bit of work to fully document this.

Before we start, it also looks like we're not always using the best BIKE code available. For instance we're using gf2x_mul_base_port instead of gf2x_mul_base_pclmul when compiling specifically for Haswell, which has PCLMUL. This is causing a lot of constant time warnings. The cpu_features.h file needs to be rewritten to be aware of the dist build setting and it needs to fall back to the oqs_config.h defines for non-dist builds.

[dstebila]

The new BIKE code has some non-constant time subroutines for some platforms, but there's definitely an attempt to be constant time on recent Intel CPUs. It will take quite a bit of work to fully document this.

Before we start, it also looks like we're not always using the best BIKE code available. For instance we're using gf2x_mul_base_port instead of gf2x_mul_base_pclmul when compiling specifically for Haswell, which has PCLMUL. This is causing a lot of constant time warnings. The cpu_features.h file needs to be rewritten to be aware of the dist build setting and it needs to fall back to the oqs_config.h defines for non-dist builds.

Should we create a separate issue to track this, allowing us to merge this PR without waiting on that?

[bhess]

Should we create a separate issue to track this, allowing us to merge this PR without waiting on that?

I can remove the BIKE part from this PR, so this can be tracked and handled in a separate issue.

[bhess]

Removed the BIKE part of this PR for the time being.

[dstebila]

Is this ready to merge?

[bhess]

yes, it's ready from my side.

[bhess]

Replaced by #1048 (with branch on open-quantum-safe project to be able to test TravisCI)