`ChannelDetails` is missing properties from original

[jbesraa]

The following properties are here but not here

	/// The available outbound capacity for sending a single HTLC to the remote peer. This is
	/// similar to [`ChannelDetails::outbound_capacity_msat`] but it may be further restricted by
	/// the current state and per-HTLC limit(s). This is intended for use when routing, allowing us
	/// to use a limit as close as possible to the HTLC limit we can currently send.
	///
	/// See also [`ChannelDetails::next_outbound_htlc_minimum_msat`] and
	/// [`ChannelDetails::outbound_capacity_msat`].
	pub next_outbound_htlc_limit_msat: u64,
	/// The minimum value for sending a single HTLC to the remote peer. This is the equivalent of
	/// [`ChannelDetails::next_outbound_htlc_limit_msat`] but represents a lower-bound, rather than
	/// an upper-bound. This is intended for use when routing, allowing us to ensure we pick a
	/// route which is valid.
	pub next_outbound_htlc_minimum_msat: u64,

[jbesraa]

@tnull, happy to add them if you think its ok

[tnull]

Yes, we've originally opted to not add all fields at once as not all made sense in the context of LDK Node, however the above mentioned should def. be exposed. Even more, most other fields would now make sense in one context or the other, so we should consider actually exposing most of them.

@tnull, happy to add them if you think its ok

Sure, please go for it!

While your at it, could you also add inbound_htlc_minimum_msat/inbound_htlc_maximum_msat/config/force_close_spend_delay, as well as ChannelCounterparty::{unspendable_punishment_reserve, outbound_htlc_minimum_msat, outbound_htlc_maximum_msat} (as counterparty_{unspendable_punishment_reserve, outbound_htlc_minimum_msat, outbound_htlc_maximum_msat}), and ChannelCounterparty::forwarding_info::{fee_base_msat, fee_proportional_millionths, cltv_expiry_delta} (as counterparty_forwarding_info_{fee_base_msat, fee_proportional_millionths, cltv_expiry_delta})? Thanks!

(Note we can't easily use the upstream LDK structs as otherwise bindings would force us to replicate all of them as interfaces, and it's probably cleaner to keep them in a single ChannelDetails struct for now.)