Remove Rainbow level 1

[dstebila]

Fixes #1260

• [YES] 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.)

[dstebila]

@baentsch Should I have also changed RainbowIII and RainbowV to have security level 1 and 3? Within liboqs that should have no effect other than to change some documentation and an information member variable. But will that cause downstream consumers to change the things they pair Rainbow with in hybrid modes? Since the Rainbow team downgraded their claimed security of Rainbow, it would be preferable to have that reflected here, but I don't want to have to go through the process of reassigning everything downstream only for us to remove it a few weeks later. I think we discussed this earlier but I can't remember the decision.

[baentsch]

Should I have also changed RainbowIII and RainbowV to have security level 1 and 3? [...] I think we discussed this earlier but I can't remember the decision.

That was part of the discussion here and there you stated

We'll remove Rainbow level 1 for 0.7.2 via #1263 and then remove the remaining Rainbow after that.

As you closed the issue there that contained all those steps with all the knock-on effects discussed there (new OIDs, etcpp), my take is "No": Lots of work for an algorithm that's broken and was not part of the NIST competition at those reduced levels. It was dropped (at the original levels). It never was nor ever will be used by anyone at those reduced levels. Thus, changing the Rainbow sec levels doesn't make any sense. Dropping the whole family would have been the most logical solution. Dropping RainbowI is an understandable "bare minimum" and that's what I understood this PR is about (assuming you'd reached agreement on this "bare minimum solution" in last week's call that I couldn't attend).

[baentsch]

@dstebila In the future, please avoid merging such a change to liboqs that we know breaks oqs-provider without also merging the matching oqs-provider PR at the same time: See the flurry of (in hindsight unnecessary) activity triggered by this: OpenSSL depends on the two components to work OK together; openssl/openssl#18899 (@bhess, @christianpaquin @xvzcf also FYI). Thanks in advance!

[dstebila]

@dstebila In the future, please avoid merging such a change to liboqs that we know breaks oqs-provider without also merging the matching oqs-provider PR at the same time: See the flurry of (in hindsight unnecessary) activity triggered by this: OpenSSL depends on the two components to work OK together; openssl/openssl#18899 (@bhess, @christianpaquin @xvzcf also FYI). Thanks in advance!

Sorry, will try to remember for next time.