disable BLISS for known side-channel attack

While enabling NTRU (that was ok) I thought I should also enable BLISS which is for the same post-quantum use cases. See bug 1863749.

But I got an info from upstream there:
Tobias Brunner (tobias-strongswan) wrote on 2020-03-05: #14
Enabling the bliss Plugin is probably not such a good idea. There is a potential local side-channel attack on strongSwan's BLISS implementation (https://eprint.iacr.org/2017/505).

The ntru plugin should be fine. However, using NTRU with IKEv2 is not standardized (uses an algorithm identifiers from the private use range etc.).

Multiple IKEv2 protocol extensions are currently being developed, for instance, additional exchanges to use fragmentation during the key exchange or using multiple and more generic key exchanges, in particular, post-quantum key encapsulation mechanisms (KEM, of which most have quite large public keys). The latter (plus signature algorithms) are currently being standardized by NIST (https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization) and versions of NTRU are among the contenders in round 2 (https://csrc.nist.gov/projects/post-quantum-cryptography/round-2-submissions). BLISS is not, but CRYSTALS-DILITHIUM is designed by the same people. It might be a while until strongSwan supports the protocol extensions (there is a branch with a partial implementation) and especially the new algorithms (we currently use the liboqs library in said branch, https://github.com/open-quantum-safe/liboqs/).

---

Based on that lets drop BLISS again and keep just NTRU.