Refactor liboqs-python classes / API changes

[truth-quark]

As per the weekly meeting, here is a PR for discussion of the code changes pushed yesterday.

The tasks & discussion points include:

• Update Py method names to match C KEM & Sig structs?
  • What about a common OO API for all the wrappers?
• Douglas: does the OQS_[KEM|SIG] represent an instance of an alg, or a general mechanism?
• Douglas: methods, secret_key as member vs method arg
• Douglas: include length checks in some of the functions
• Douglas: do KAT tests somewhere?
• Wrapper doesn't support nist-branch Sig interface at present
• Should vars in the 'details' dict be moved into the class, and then replace 'details' with a Py getter property?
• Ben: defer when the SO is loaded for testing?
  • _load_shared_obj() is called during import, which sets up the liboqs var. Loading liboqs is coupled to import time, which is a bit problematic
  • can't monkeypatch _load_shared_obj() until after the wrapper has been imported
  • some parts of the code can't be tested due to the above, unless there's refactoring

[dstebila]

• Douglas: does the OQS_[KEM|SIG] represent an instance of an alg, or a general mechanism?
• Douglas: methods, secret_key as member vs method arg

I think I'd prefer OQS_[KEM|SIG] to represent the algorithm, but not contain the keys. In other words, keypair always returns both a secret key and a public key, and then decapsulate takes the secret key as input. And one could use the same OQS_KEM object to generate many keypairs and encapsulate/decapsulate with many different keypairs.

[christianpaquin]

I create these classes with more of a object-oriented design, to simplify the job of the developer (same as in the C# wrapper). The developer might never need to export the KEM private key for a PQ exchange, so keeping it in the class abstracts this complexity away. The key can is available through its own variable if needed. Otherwise, we're forcing all devs to implement similar classes about our wrapper to hide the complexity to their own app.

[dstebila]

Ready to merge or still work to do?

[christianpaquin]

I tested the latest commits on Linux and Windows; works for me.

[truth-quark]

Ready to merge or still work to do?

If folks are happy with the class refactoring etc, I'd say merge & let others try it out.

There's several open ended questions in the ticket. but I can copy them to the wiki & convert to tickets as needed. It's probably better to have Travis working before making more structural changes.