Expose ZFEC functionality via the C-compatible FFI interface

[exarkun]

It would be nice to use Botan's ZFEC implementation from languages/runtimes other than C++. The obvious way to enable this to add a extern "C" style interface on top of the C++ interface, similar to how other functionality is exposed in src/lib/ffi/.

A reasonably simple interface to use might be something like:

// input gives the primary shares
// size gives the length of the primary shares (all equal)
// output gives a place to write a uint8_t** giving the generated secondary shares
// outputSizes gives a place to write size_t* giving the size of the generated shares (all equal)
// memory ownership of *output and all contained pointers and *outputSizes is given to the caller on success
int botan_zfec_encode(size_t K, size_t N, const uint8_t input[], size_t size, uint8_t ***output, size_t **outputSizes);

// shares gives primary or secondary shares to decode
// share_indexes gives the index of corresponding elements of shares
// num_shares gives the length of shares and share_indexes
// share_size gives the length of each share
// output and outputSizes are like for encode
int botan_zfec_decode(size_t K, size_t N, const uint8_t shares[], const size_t[] share_indexes, size_t num_shares, size_t share_size, uint8_t ***output, size_t **outputSizes);

A different interface could use output_cb_t instead of output buffers which might enable less copying but it's also harder (but maybe not impossible to consume across an FFI interface).

This interface does not preclude the addition of such an interface later on, if it proves desirable enough to do the extra work.

I have a preliminary implementation of botan_fec_encode that I've demonstrated works when called from Haskell. I can finish it (docs, tests, whatever else it needs) and work on botan_fec_decode if this addition is welcome.

[exarkun]

My work on botan_fec_encode is in https://github.com/PrivateStorageio/botan/tree/3190.ffi-zfec.

Is there interest in having this in Botan or should I work on putting this code into a different project?

[randombit]

Yes we'd be happy to take this as a PR (probably would need some additional tests/etc before merge but the general approach seems fine)

[exarkun]

I think #3196 is in reasonable shape for a first review. I'm sure I got many things wrong. There is at least a passing test that verifies the round-trip behavior for encode/decode. Looking forward to any feedback.

[randombit]

Done! Will be available in 3.0.0 which is estimated to be released sometime next month.