Consider bumping the `max_funding_satoshis` default value

[tnull]

Currently, max_funding_satoshis is still defaulting to a non-Wumbo default value.

We should consider bumping it, especially given that post-splicing the go-to default should be establishing one large channel per counterparty rather than having a bunch of smaller ones.

[TheBlueMatt]

One reason we've left it is that an application built with LDK is likely initially in beta. We have left the default there as a safety harness for applications when they're initially built. We don't really expect applications to leave it at the default forever.

[TheBlueMatt]

Not to say that we shouldn't change it, LDK has matured a lot since wumbo wasn't a thing, but I'm not sure we have as strong a desire to do it as LDK Node might.

[tnull]

Not to say that we shouldn't change it, LDK has matured a lot since wumbo wasn't a thing, but I'm not sure we have as strong a desire to do it as LDK Node might.

If we're increasingly confident in the code and we expect ~all users to bump the limit, is there any reason why we can't just drop it entirely? It seems that would be preferable to just pick (or have the user pick) a random value, and users can always limit risks through any of the other limits and/or by selecting which channels or HTLCs the accept?

Plus, it seems our current implementation is wrong, as we announce support for the Wumbo/option_supports_large_channels by default in ChannelManager, irrespective of what max_funding_satoshis value is configured. So we announce the larger-channel feature via IN to only then reject large inbound channels if they don't match our limit.

Now opened #4318 to propose this.