Botan 3.0: Cannot create custom sub-classes of Botan::Private_Key

[reneme]

With a55e4b2 the pk_ops.h header became private, only the pk_ops_fwd.h header stayed public. That's not enough to create custom sub-classes of Botan::PK_Ops::* and prevents downstream applications from implementing their own public-key algorithms.

For instance, applications might want to do that to offload public-key crypto to custom hardware. Another use case is implementing custom hybrid schemes; e.g., combine a classical with a PQC algorithm.

This may become a showstopper for some applications migrating from Botan 2.x to 3.x. I'm assuming that preventing applications from doing that wasn't intentional, @randombit? The obvious fix is to promote pk_ops.h to a public header and write a dedicated example applications demonstrating a custom public-key algorithm, as a sort-of regression test.

This is closely related to #3867.

[securitykernel]

This is IMHO really a crucial feature and I think what partially led to the current regression is that we (1) failed to document it properly and (2) are missing tests for it. A good place for tests may be examples?

[reneme]

I do think that a comprehensive example (as proposed in #3879) is the best way to "regression test" this.

On that note: Currently, the build system (read: make examples) does not prevent us from including internal headers in example files. We should find a way to fix this.

[reneme]

Currently, the build system does not prevent us from including internal headers in example files.

See: #3880