Merge pull request #127 from TheBlueMatt/main

Add missing `UtilMethods` export and sanity-test node-net setups

[TS] Update auto-generated bindings

Add missing export of `UtilMethods`

[TS] Throw a reasonable error if two `NodeLDKNet`s are on one `PM`

Revert "Use yesterday's rustc on OSX as the release binaries were built with it"

This reverts commit df806a3a7287441c2f27cb44135e3cb06ee83b42.

Merge pull request #126 from TheBlueMatt/main

0.0.114.0

Use yesterday's rustc on OSX as the release binaries were built with it

Work around rustc regression in 1.68 on android

Export more CCs in an attempt to get OSX builds deterministic

Work around actions brokenness

Update OSX CI build to LLVM 15.0.7 (matching release builds)

Update CI branches to LDK 0.0.114

[TS] Update auto-generated TS bindings

[Java] Update auto-generated Java bindings

[TS] Slightly improve logging in TS trait calls that fail

Not actually 100% sure what we can do much better on the logging
front, but this is at least a marginal improvement.

Fixes #125.

[Java] Allow the user to hook route-finding when using CMC

[Java] Expose the ProbabilisticScorer from the CMC correctly

We'd previously exposed a race-y version of the ProbabilisticScorer
where its held within a lock but also made public with no threading
requirements placed on it.

This resolves that issue by exposing it via a wrapper that holds
the score lock.

[Java] Expose the finalizer of traits, as some traits are locks

[Java] Update tests to latest (0.0.114) LDK API, rm non-hu ones

The old non-human-object-based tests don't really have any
business being held on to, so we simply remove them entirely here,
relying on the `HumanObjectPeerTest` to do all our work.

[Java] Update batteries to latest upstream (0.0.114) API

This also fixes a bug where we allowed multi-threaded access to the
`ProbabilisticScorer` without the lock required to make it safe.

[TS] Update tests to latest upstream (0.0.114) LDK API

Support traits with supertraits of supertraits

Support (fixed-length) arrays of 16-bit integers

Ensure enums generate a ref in owning structs

Previously we only added a ref in an owning struct to an enum if
that enum contained a trait in a field. This isn't sufficient as an
enum could still contain a reference to an opaque object, which
needs to stick around as long as the enum exists.

For simplicity, simply add a ref in all cases as it seems to still
work in our own internal tests.

[TS] Remove unused variable in generator

Pass fewer link-only args to compilation clang

Merge pull request #124 from TheBlueMatt/main

Update to 0.0.113

[TS] Update CI libicu package

Fix WASM CI build due to Actions being trash

Fix OSX CI to *actually* use upstream clang

[C#,Java] Fix building on OSX due to bug in latest ld64.lld/clang

[OSX] Update LLVM/clang to 15.0.3 (the latest x86_64 version)

Update CI references to 0.0.113

[C#] Check in initial auto-generated C# bindings

[C#] Add initial hooks, the C# code compiles, the C not at all

[Java] Update tests to 0.0.113 API

[TS] Update tests to 0.0.113 API

[TS] Update auto-generated TS bindings to 0.0.113

[Java] Update auto-generated Java bindings for 0.0.113

Add some additional writing hooks which C# needs

[Java] Use util method where possible

[Java] Drop unused util methods

[TS] Support one more call function

New manual U5 (from u5) and Witness types

Add support for U128, passed as [u8; 16] but with human wrappers

Pass array type, not subty to primitive_arr_*_hu for more context

Remove args_known and fix `(void)` parsing (duh, its no arguments)

Merge pull request #123 from tnull/patch-1

Update bindings branch to v0.0.112

Update bindings branch to v0.0.112.

Only set up `NioPeerHandler` after chain sync completes

No peer connections must be made until after `chain_sync_complete`
is called when using the `ChannelManagerConstructor`, so
initializing the `NioPeerHandler` before then just tempts fate and
risks doing Bad Things.

[Java] Always log the LDK versions on startup

Merge pull request #120 from TheBlueMatt/main

Update to 0.0.112 (with RGS)

Update CI references to 0.0.112

[TS] Update auto-generated TS bindings

[Java] Update auto-generated Java bindings

[TS] Be more aggressive with type checks

[TS] Apparently `console.log` doesn't actually throw, it just logs

[TS] Update TS Tests to latest upstream API and test OMs

[Java] Update Java Tests to latest upstream API

[Java] Update ChannelManagerConstructor to latest upstream API

[TS] Handle nullable arrays and objects in more cases

[Java] Handle nullable arrays

Handle optionally-null multi-dimentional arrays with null check

[TS] Fix calling trait methods which return a simple enum

[Java] Fix calling trait methods which return simple enums from C

[TS] Test ChannelManager future notify completion

This is broken upstream in LDK, so needs fixing there.

[TS] Update auto-generated bindings (with RGS)

[TS] Correct encodeUint64Array array view length

Otherwise the `set` call fails as the array view we've constructed
is only 1 element long.

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