Merge pull request #119 from TheBlueMatt/main

Update to 0.0.111

[TS] Update auto-generated TS bindings

[Java] Update auto-generated Java files

[TS] Test OnionMessenger in TypeScript tests

[Java] Update ChannelManagerConstructor and tests to latest API

[TS] Update typescript tests to latest upstream API

Update CI references to 0.0.111

[TS] Fix generation for traits that have supertraits

When we have a trait with a supertrait, we have to pass both the
main- and super-trait instance indxes through to C so that it can
call both. We failed to do this, missing an argument entirely when
calling the C code.

Instead of trying to allocate a new instance index, we opt to store
instance indexes in trait structs (assuming there is one) and then
reuse the one in the constructed object.

[TS] Correct TS call semantics for some function types

TS functions now all return uint64_t, not uint32_t, for pointers.

Allow trait methods to return NULL-able objects

The comment claiming this isn't supported in Java/TS is incorrect -
it works just fine with no further modifications.

Add support for mapping LDKBigEndianScalar manually, ala TxOut

Merge pull request #117 from TheBlueMatt/2022-08-fix-npe

[TS+Java] Ensure we don't try to add a reference from null.

[TS] Update auto-generated file

[Java] Update auto-generated Java structs

[TS+Java] Ensure we don't try to add a reference from `null`.

At least in `Event::PaymentPathFailed` if we try to map an event
with no `retry` we'll hit a `NullPointerException` as we'll try to
add a reference from the `null` retry back to the `Event` itself.

The simple fix is to simply exhaustively check for `null` before
adding references everywhere.

Merge pull request #116 from TheBlueMatt/main

Handle socket errors (the same as socket closure)

Handle socket errors (the same as socket closure)

`gr0kchain` on Discord reported that not handling "error" causes
us to get unhandled exceptions, so we have to handle it.

Merge pull request #115 from TheBlueMatt/main

[TS] Update auto-generated TypeScript bindings

[Java] Update auto-generated Java bindings

Add test for gossip data fetching

This tests the changes in  #114 for regression, and failed prior to
 #114.

Drop clone on tuple-field-fetching

Early in the lifetime of the bindings here tuple-field-fetching
had memory tracking issues which appear to have been solved now.
Thus, we can go ahead and drop the clone, at least for has-inner
types.

Fixes #84.

Merge pull request #114 from TheBlueMatt/main

Change where the opaque struct is_owned bit is stored in pointers

[Java] Update auto-generated Java bindings

[TS] Update auto-generated TS bindings

Switch 32-bit platforms to using 64-bit "pointers"

This much more cleanly fixes the issue described in the previous
commit by simply using 64-bit integers to represent pointers on
32-bit platforms, letting us store the required flag bit in the top
32-bits that are always free.

It does, however, imply changing the entire call semantics for
TypeScript to use BigInts for pointers, rather than numbers.

Change where the opaque struct is_owned bit is stored in pointers

When we're returning a reference to an opaque struct, we previously
used the LSB to track the is_owned bit. This works for
heap-allocated structs just fine as `malloc` guarantees maximal
(usually 8-byte) alignment for all returned pointers. However, for
opaque structs which are actually a reference to a field in a
larger native Rust struct (eg `NodeId` in
`ChannelDetails_get_node_one`), this may not be the case. This
caused reading off-by-one `NodeId`s.

We fix this by adding a new set of utilities which handle tagging
and un-tagging pointers which are a bit more complicated. One
32-bit platforms, we simply use the low bit but will change that
in the next commit. However, on 64-bit platforms we have to be a
bit more careful. Modern 64-bit platforms, including Android, use
the top bits (8 bits in the case of android) for pointer
authentication. x86_64 sets the top 16 bits to the same value, but
they may be 1s or 0s. Thus, we use (9th bit) ^ (10th bit) as our
tag, assuming that they are always equal.

This isn't the most robust solution, but until there's time to
rewrite all the opaque object handling to fetch java fields from C
this is likely the best we're going to be able to do.

Merge pull request #113 from TheBlueMatt/main

Update to latest LDK-C-Bindings and fix assorted TS bugs

[Java] Update auto-generated Java bindings with new upstream getters

[TS] Update auto-generated bindings with changes + upstream changes

[TS] Ensure uint64_t arrays are 8-byte aligned by using an 8-byte len

[TS] Redo C -> TS call function naming to make it harder to screw up

Merge pull request #112 from G8XSU/main

Use Gnu-sed on macosx if available

[TS] Call FinalizationRegistry.register with a unregister token

We were assuming we could use `unregister` but weren't actually
passing an "unregister token", which causes unregister to not
function properly.

[TS] Include substantially larger backtrace in testing

[TS] Support lock structs by requiring manual free calls

[TS] Fix fd_write to match the ABI, quiet environ call logging

We need to return the bytes written via an extra argument that we
were leaving potentially-uninitialized.

[TS] Support mapping returned uint64[]s from rust functions

Use Gnu-sed on macosx if available

Merge pull request #111 from TheBlueMatt/main

[Java] Add a simple read lock call in HumanObjectPeerTest

[Java] Fix undefined behavior in HumanObjectPeerTest

CI somehow convinced the access to custom_messages_to_send to
trigger an `ArrayIndexOutOfBoundsException`, which should not be
possible except in race cases due to threading issues. Adding the
missing synchronized block should address it.

Merge pull request #110 from TheBlueMatt/main

Update to LDK 0.0.110

[TS] Update auto-generated TS bindings to LDK 0.0.110

[Java] Update auto-generated Java bindings to LDK 0.0.110

[Java] Update tests to latest upstream API

Update CI references to LDK 0.0.110

Merge pull request #107 from TheBlueMatt/main

[TS] Properly export unitary enums such that they're in *.d.mjs

[TS] Update auto-generated TS bindings

[TS] Add a socket handling implementation that uses Node.JS's `net`

[TS] Add additional node API interface bits for net

[TS] Add missing space in array length error string

[TS] Properly export unitary enums such that they're in *.d.mjs

Because the `ts/enums/*` files simply re-export from `bindings.mts`
rather than defining the enum from scratch, we have to include docs
and cannot use /* @internal */ on the `bindings.mts` unitary enums.

[Java] Strip Java binaries when compiling, not just wasm

Merge pull request #109 from dunxen/patch-1

Specify Node version for Wasm BigInt support

Specify Node version for Wasm BigInt support

From Node v15.0, Wasm BigInt support is no longer experimental

See: https://github.com/nodejs/node/commit/ca8f3ef2e5

Merge pull request #106 from TheBlueMatt/main

0.0.109.0

Update CI branches to 0.0.109

[TS] Update auto-generated TS bindings

[Java] Update auto-generated Java bindings

[Java] Update tests to match 0.0.109 API

Merge pull request #104 from TheBlueMatt/main

Fix TS u64 call semantics (and test it)

[TS] Explicitly include `index.d.mts` (and `.mjs`) in package

As apparently npm doesn't include it just because its listed in
`types`.

[TS] Auto-update version in package.json in genbindings.sh

[TS] Update auto-generated typescript bindings

[TS] Add a test that uses `PeerManager` to exchange channel open

[TS] Fix typo in inconsistent-versions error message

[TS] Free arrays passed as slices from TS -> C -> Rust

[TS] Split C -> JS function calls based on u32/u64 parameters/return

We were calling all C -> JS functions with u32 parameters and
return types. This is fine for all of our pointers, as well as any
smaller types - u32 always gets mapped to a JavaScript `number`, so
its all consistent.

However, for u64 parameters/returns, we map the values to
JavaScript `bigint`s, which are not compatible with `numbers`, and
the correct type is checked at the FFI when returning or when users
ultimately try to use a passed `bigint` as if it were a `number`.

Thus, we have to split the `js_invoke_function` family by the
parameters and return values, using `u` for u32s and `b` for u64s
to do so.

Merge pull request #103 from TheBlueMatt/main

0.0.108.0

Update CI install to match latest debian bookworm state

Update CI MacOS clang version to 14.0.5

Update CI cbindgen install script to work with MSRV

Update CI bindings branches and tags to 0.0.108

[TS] Update auto-generated typescript bindings

[TS] Update tests to new upstream API changes in 0.0.108

[TS] Link wasm32-wasi libc as rustc no longer does by default

[Java] Update auto-generated Java bindings for 0.0.108

[Java] Handle different ldk lib paths in the ar in genbindings.sh

[Java] Use public channels and test Access interface in tests

[Java] Update batteries and tests to 0.0.108

This is mostly pretty obvious changes to keep up with the latest
API, though it also includes a change to make `PeerTest` work
correctly in a world where `PeerManager` supports multithreaded
parallel access.

[Java] Do not put a org.ldk.structs prefix for usize types

[Java] Map `LDKReadOnly*` the same as `LDKLocked*` ie via `AutoClosable`

Pass unnamed enum field comments through to field processing

Add handling for the new WitnessVersion type, similar to u5 but 4-bits

Use fully-qualified types more often in conversions

This ensures to-human conversions still work correctly inside
enums where there is an enum variant named identically to the type
which is being converted to (eg in the new `GraphSyncError` enum).

Merge pull request #100 from TheBlueMatt/main

Add note about garbage collection of the chan man constructor

Add note about garbage collection of the chan man constructor

Merge pull request #98 from tnull/2022-05-fix-genbindings-aarch64

Some fixes for aarch64 macos

Some fixes for aarch64 macos

Merge pull request #97 from TheBlueMatt/main

[Java] Fix PATH order to use upstream clang in OSX CI

[Java] Fix PATH order to use upstream clang in OSX CI

Thanks to @tnull for spotting this one.

Merge pull request #96 from TheBlueMatt/main

[Java] Correct trivial race condition in HumanObjectPeerTest

Update ts bindings version to 0.0.106.0beta1

[Java] Correct trivial race condition in HumanObjectPeerTest

On my (very slow) old armv7 device, HumanObjectPeerTest can fail as
`maybe_exchange_peer_messages` will set `ran = false` *after* a
message is added to the runqueue, but before it runs, then when we
call `process_events` there will be no events to process, then
before we get into the `runqueue` `synchronized` block the message
will be delivered, causing us to think we're done, even though
there are now events pending. Because going around the loop twice
is free, we should just not set `ran` to false at the top of
`maybe_exchange_peer_messages`.

Merge pull request #95 from TheBlueMatt/main

Convert primitives before passing to host language

Update OSX CI clang to 14.0.1

[TS] Update auto-generated bindings

[Java] Update auto-generated bindings

Convert primitives before passing to host language

This resolves an issue where we map unsigned primitives to their
signed variants, and occasionally pass the unsigned variant (which
is outside the bounds of the signed variant) to the host language.

In Java this can cause a panic as the VM sees an int outside the
range of a short (for example with network ports).