Kyber/Dilithium copy_from_upstream

[bhess]

Updates Kyber and Dilithium from upstream.

• Fixes build issues with GCC 11.1 for Kyber and Dilithium (Typing fixes for compiling on GCC 11.1 pq-crystals/dilithium#53 and Typing fixes for compiling on GCC 11.1 pq-crystals/kyber#43)
  -> needed for resolving Many schemes fail to compile with GCC 11.1.0 #1035
• Points to upstream version with updated Dilithium author list (yml update - authors pq-crystals/dilithium#50)
  -> unblocks do full upstream doc generation [skip ci] #1066

• 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 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.)

[bhess]

Cygwin build is still failing, but now because of NTRU. https://ci.appveyor.com/project/dstebila/liboqs/builds/40745601/job/v897nkevowfh4xx8

[baentsch]

Basically LGTM. Can you (have you already) confirme(d) that running the code of #1066 creates good docs with this? And/or would you want to run it and add the resultant docs to this PR?

[bhess]

Basically LGTM. Can you (have you already) confirme(d) that running the code of #1066 creates good docs with this? And/or would you want to run it and add the resultant docs to this PR?

Thanks, I added the generated docs as a commit to this PR. The output looks ok/consistent with the upstream yml. The only thing I added manually after running the script from #1066 is the upstream-tag value (i.e. https://github.com/pq-crystals/kyber/commit/faf5c3fe33e0b61c7c8a7888dd862bf5def17ad2 with copy_from_upstream patches)

[baentsch]

Thanks for running it & making this PR more complete.

The only thing I added manually after running the script from #1066 is the upstream-tag value

May I ask where? Does #1066 need an update then (as no manual change should be necessary after merging it)?

[bhess]

May I ask where? Does #1066 need an update then (as no manual change should be necessary after merging it)?

The updates analogous to https://github.com/open-quantum-safe/liboqs/pull/1066/files#diff-62acaa75033d46002846a422e8f7b75cb554c35903d439f38b44b8bdf524e3ceR20-R21 were not done automatically by the script from #1066. Is there an option for the script to do this automatically?

[baentsch]

The updates analogous to https://github.com/open-quantum-safe/liboqs/pull/1066/files#diff-62acaa75033d46002846a422e8f7b75cb554c35903d439f38b44b8bdf524e3ceR20-R21 were not done automatically by the script from #1066. Is there an option for the script to do this automatically?

I don't recall that -- and upon quickly glancing the script over, didn't see logic for this. Can I ask @xvzcf to take a look? If I recall correctly, I only changed logic pertaining to KEMs and SIGs, not global YML fields from your original script (sorry there's no diff due to the file renaming). If you don't have time today, I'll try to resolve this tomorrow.

But this PR should be merged. #1066 basically should become a no-op (this time -- and work automatically next time).