API Improvements - Expose peer API, allow custom packet producer/consumer

[ngc0202]

Hi all, I love this project as a drop-in replacement for kernel WireGuard, but the library API could use some fleshing out to broaden the usability of this crate as a library. Here are some features I'd love to see added:

1) Documentation! Thought I'd start here before actual features since it really hampers usability to have the entire crate undocumented. Examples would go a long way too.

2) Public API for querying and manipulating peers that were added over the sock API rather than through the library. Currently there is no access to this whatsoever, which means a library based on boringtun which expects to be configured by wg has absolutely zero access or control over anything - all you can do is drive the event loop and wait.

3) Internal processing of packets. This is the big one for me - the entire reason I was attracted to wireguard-as-a-library as this crate provides is so I could avoid the need for the tun interface to send and receive packets through WireGuard, and instead do this directly from my application without getting the kernel involved. This could maybe be done using a trait for a generic producer/consumer of IP packets so that it could be configured to use tun by default, but also let a library user of this crate implement their own drop-in replacement.

Thank you for putting together this project, it's a great addition to the Rust ecosystem and the library half of this project has a lot of potential to allow for very flexible custom behavior using the WG protocol.

[KOLANICH]

1. I think this library should be splitted into multiple libraries and multiple crates, each one with C API. And the libraries implementing protocols should not do any io themselves. It can be possible to implement a library both doing io and using wireguard, but it should be a separate shared library in a separate crate. Also that high-level library will likely have to involve a userspace tcp/ip stack. I insist that that high level lib must not use any specific TCP/IP stack, instead it should use an abstract interface (available as a separate crate) and there should be wrappers implementing those interface for existing good userspace stacks. Also there should be a lib using kernel to do the same job. It may be slower and requiring root, but it is useful for comparison of behavior of userspace tcp/ip stacks with kernel-based impls and also will help to test the test suite itself. The test suite, of course, must test only the interface and its behavior, not the impl details of different libs.
2. I think the library implementing wireguard protocol (the one now exposed through C API) should not touch packets at all. I mean we should be able to use that library as a dumb pipe. I mean it should be possible to feed it with any data that are not valid packets and get the exactly the same data from another end of the tunnel. The layer touching packets should be an another layer in an ankther shared library.

[lu-zero]

It would also make easier to port it to wasi.