[net] Ensure we don't spin loop by keeping the poll write bit set

Previously we'd not been unsetting POLLOUT, which will result in
us spin-loop'ing with ChannelManager_write_buffer_space_avail.

Further, we'd also not been unsetting the POLLIN bit, which would
result in us never pausing read as the SocketDescriptor API
requires us to.

Merge pull request #45 from TheBlueMatt/main

Correct clone logic for `Str`.

Update auto-generated bindings to latest upstream

Update git commit dependency to latest upstream

Correct clone logic for `Str`.

Previously we'd blindly clone'd the fields, which, if
`data_is_owned` is set, will always result in a a double-free.

Instead, we always clone the underlying bytes, setting
`data_is_owned` on the returned value since its likely the caller
wants to hold onto the string outside of the current context.

Merge pull request #44 from TheBlueMatt/main

Detect a type as clonable with an explicit `impl Clone`

These stay `impl Clone` even after the pretty-print rustc pass so
we cannot only match `core::clone::Clone`

Fix races in demo C++ bindings that can hang valgrind in CI

Cache multi-line sed replacements across methods to improve runtime

Merge pull request #43 from TheBlueMatt/main

Link libm for debug builds in testing due to new rust libstd dep

Link libm for debug builds in testing due to new rust libstd dep

Merge pull request #42 from TheBlueMatt/main

Update to v0.0.101

Bump lightning dep gitish to v0.0.101

Update C and C++ demos to latest API and test custom messages

Update auto-generated bindings

Call clone explicitly to avoid deref recursion when cloning traits

Add missing C++ header for LDK::Str

Stop tracking unused syn::Type mappings in GenericResolver

They are now unused as of the previous commit

Use `GenericTypes`'s type resolver instead of re-resolving

When we resolve a type with `GenericTypes::maybe_resolve_path` it
returns a resolved-path string as well as a syn::Path. When
resolving we'd previously then re-resolve the Path with the current
type/import information, instead of just accepting what was already
resolved. Simply accepting what was already resolved not only
simplifies a few cases, but also allows us to clean up where the
"crate::" prefix is printed, keeping "crate::" prefixes out of all
type resolution.

Work around broken resolution on non-pub use aliasing in another module

Handle uncallable trait methods that use Infallible in a parameter

Map core::convert::Infallible to a similar manually-defined struct

Support std::io::Read natively by mapping it to and u8slice

Support converting C `OutPoint`s to `bitcoin` `OutPoint`s

Update io::Read manual implementation to upstream API changes

Avoid mapping optionals as owned pointers

Using an owned pointer to map an optional turned out to be quite
annoying to avoid downstream memory issues. Instead, we use the
much more explicit `COption_TypeZ` enums everywhere.

This also fixes Option-al mapping of enums.

Handle `W: X<T = Y>` generics where `Y` is used as `Z<Y>`

This simply requires calling `resolve_type` in a few more places.

Call methods explicitly on traits to avoid to deref recursion

Correct printing generic methods in traits

If a trait method is generic (and not the object itself), we
previously would print the concrete resolved types in the
`impl nativeTrait for TraitStruct` block instead of the generic
names, leading to compilation failures.

Learn supertrait associated types when processing traits

Define a macro for constructing a TypeResolver for a given module

This is used to resolve types referenced in modules other than the
current one.

Support mapping core::fmt::Debug as a supertrait

Test fetching a Vec<Vec<Opaque>> via a generated getter in C++ demo

Support mapping slices which contain slices which contain opaques

Fixes https://github.com/lightningdevkit/ldk-garbagecollected/issues/43

Map Vecs to slices when constructing a getter for a public field

This adds logic to allow constructing a getter for a public Vec
field where the inner items are opaque structs. In order to do this
we map them as slices, which will end up generating Vecs with
elements which all have their `is_owned` flags unset.

Drop debug print that slipped in in a previous PR

Merge pull request #40 from TheBlueMatt/main

Differentiate inner pointers representing None and Some(ZST)

Update git hash to latest upstream

Update auto-generated bindings to latest upstream

Update auto-generated bindings

Build native debug binaries with --cfg=test_mod_pointers

Differentiate `inner` pointers representing `None` and `Some(ZST)`

For zero-sized-types, rust `Box::into_inner(Box::new(ZST {}))`
returns `1usize as *mut ZST`, which confuses our Java bindings
which check for `None` by checking if `inner < 1024`. While we
could convert the Java bindings to check for `inner == 0`, the
magic value for ZST pointers is not, to my knowledge, an ABI
guarantee Rust provides.

Instead, we add an offset to the `inner` pointers to push them
past the zero page for ZSTs, taking this opportunity to clean up
some of our pointer conversion and push them through a common set
of utility functions.

We also add testing infrastructure to add similar offsets to
non-ZSTs to get good test coverage of the offset addition-removal,
though Rust should largely be ignoring pointer values for ZSTs
anyway so there should be little risk in anything going wrong here.

Merge pull request #39 from TheBlueMatt/main

Update to 0.0.100

Use v0.0.100 for lightning-c-bindings rust-lightning dep

Commit latest auto-generated C bindings based on 0.0.100

Add support for bitcoin::hash_types references and NonZeroU8

Merge pull request #38 from TheBlueMatt/main

Provide full (new) struct to trait clone functions

Update auto-generated bindings

Update git hash to latest upstream

Bump rust-bitcoin dependency to match rust-lightning

Add utility method to construct new complex enums

This is incredibly useful for downstream languages eg Java as it
avoids having to manually implement constructors and can just use
common function-mapping logic.

Note which parameters or return values are (secretly) Options

Because `Option<OpaqueType>` is mapped the same as `OpaqueType` its
not immediately clear which values in the API are actually
`Option<>`al. Thus, we should at least have documentation noting
this.

Expose struct method calls on trait structs to C++ directly

We can add method calls for non-trait structs later, but this is
particularly useful as otherwise you need to extract both the
method and the `this_arg` to make the call.

Update C++ demo and ldk_net to new clone API

Update C++ demo to new upstream changes

Provide full (new) struct to trait clone functions

Previously, when we went to clone a trait-implementation struct,
we'd provide only the `this_arg` void pointer, requiring that the
`this_arg` pointer be cloned into a new object while all remaining
fields are copied over exactly.

This has a few important limitations:
 * When a struct is cloned, it is not possible to set a `free`
   function to free any new data placed in `this_arg` without it
   also being set on the original struct.
 * Supertrait fields cannot be updated in the subtrait clone
   method, including the `this_arg` and `free` methods.

The first limitation prevents us from setting `free` after a clone
when the original trait may or may not have had `free` set. For
example, if the original trait was created with a `Obj_as_Trait`
method, cloned copies would never be free'd.

The second limitation prevents us from keeping the super and
subtrait `this_arg` fields in sync, in addition to limitations
similar to the above.

This resulted in Java code double-free'ing the `this_arg` field in
`InMemorySigner` objects which were accessed as both `Sign` and
`BaseSign` traits.

Correct args passed to supertrait C methods in subtrait impls

Copy PeerManager pointer in ldk_net

Swap include <> for include "" to make downstream Swift projects happy

If we're leaving binaries around, use -fPIC for ldk_net.o

This is needed if downstream projects want to just take our
ldk_net.o binary and link them in directly, eg with addrsan to
avoid figuring out exact compile flags.

Fix LLVM version-suffixed binary name checking

Most hosts will install clang/LLVM binaries with the -MAJOR_VER
suffix, but we were searching for -MAJOR_VER.MINOR_VER suffix.

Merge pull request #36 from TheBlueMatt/main

Fix Determinism with Newer Rustc and support additional targets (for Android)

Enable macos-11 in CI

Apply metadata replacement to ldk library as well for new rustc

Add extra targets env variable to build for extra targets (eg Android)

Merge pull request #35 from TheBlueMatt/main

Update build-std parameters

As suggested at https://github.com/rust-lang/wg-cargo-std-aware/issues/71#issuecomment-877403993

Set compiler flags earlier to get -isysroot in all RL builds

Merge pull request #34 from TheBlueMatt/main

Add a POSIX C LDK networking library

Update Cargo git hash to upstream v0.0.99

Update auto-generated bindings to latest upstream

Update C++ bindings demo to latest upstream API

Use correct lld to match rustc LLVM version (if available)

Drop -flto from non-cross-language-lto C++ demo builds

It appears somehow the LLVM IR is slipping into the Rust library,
causing Ubunto link to fail with the following error:

/usr/bin/ld: error: LLVM gold plugin has failed to create LTO module: Invalid record
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Add a POSIX C LDK networking library

Skip trait typedef in extra header as its unnecessary

... and OSX complains that "redefinition of typedef...is a C11
feature"

Drop rust-secp256k1 patch as it has been merged into a release upstream

Merge pull request #31 from TheBlueMatt/main

Fix aarch64 targeting and print an error if its disabled

Drop clang GH actions cache as it appears broken on OSX

Drop MacOS 11 runner until we get access to private preview

Fix aarch64 targeting and print an error if its disabled

Merge pull request #30 from TheBlueMatt/main

Clean up OSX support and build for aarch64-apple-darwin

Add OSX CI

Also build for aarch64-apple-darwin if we're building on x86_64 OSX

Clean up OSX support and rustc path selection somewhat

Merge pull request #29 from TheBlueMatt/main

Update to upstream 0.0.98

Update auto-generated bindings to upstream 0.0.98

Switch rust-lightning dep to upstream now that we're "stable"

Update git HEAD to upstream 0.0.98

Update bindings C++ demo to latest upstream (0.0.98) API

Only set -mcpu=sandybridge on x86_64

Drop spurious deref when converting Vec entries to C

Merge pull request #28 from TheBlueMatt/2021-06-fix-nondeterminism

Fix various sources of build non-determinism and default to targeting sandybridge (ie AVX)

Ensure we sanitize rustc random values for all lightning crates

Use 16 hexits for git describe to avoid nondeterminism

Set LC_ALL and -frandom-seed to avoid common nondeterminism sources

Swap default-cpu for sandybridge and use it when compiling libsecp

sandybridge is a reasonable choice because it supports AVX but is
also 10+ years old (with AMD support for AVX at similar times).

The next option would be haswell with AVX2, which doesn't add as
much and for which AMD processors only came about in mid-2015.

Merge pull request #27 from TheBlueMatt/main

Fix race in C++ demo where num_txs_broadcasted ++s before =0s

Fix race in C++ demo where num_txs_broadcasted ++s before =0s

Merge pull request #26 from TheBlueMatt/main

Update rust-secp patch to match latest version and bump upstream