Do not merge user provided features with defaults

[araspitzu]

Currently we always merge the features defined by the user in eclair.conf with our reference.conf file, this led to some unexpected behaviors as described in #1434.
The PR corrects this behavior by making sure we never merge our default features with the user defined features, if the user provides some value then we use only that and if it doesn't we fallback to our hard-coded default features. Note that this makes impossible for a user to completely disable all features (i.e setting features { }) but i think it's okay because it doesn't affect any actual use-case.

Because of #1434 we need a way to let the user disable the default features. This PR explicitly allows to disable any feature from the configuration by setting disabled near the feature definition, all features are defined in the reference conf even if not active by default.

[pm47]

Rebased, and added a commit to improve the toString:

features=initial_routing_sync:optional,option_data_loss_protect:optional,var_onion_optin:mandatory
features=gossip_queries_ex:optional,basic_mpp:optional (unknown=5)
features= (unknown=25,28,30)

[t-bast]

Aren't we also missing option_static_remotekey = disabled and keysend = disabled if we need to specify all features?

[pm47]

This shows the ambiguity that "not defined by default" == "defined as disabled" 🤷‍♂️

[t-bast]

I tested and it doesn't look like we need to explicitly disable not-defined-by-default features...
So we should either:

• remove that line and keep option_static_remotekey and keysend absent as well
• or include them all?

I slightly prefer the second option where the reference.conf lists all supported features, with some of them disabled.
It makes it easier for users to figure out what features they can enable/disable without having to look at the actual code.

[pm47]

I tested and it doesn't look like we need to explicitly disable not-defined-by-default features...

Indeed, I see the disabled one as an example on how to explicitly disable other features that are enabled by default.

I slightly prefer the second option where the reference.conf lists all supported features

I bet new features will be forgotten...

The more I think about it, the more I think we should just rely on the null trick as laid out in the HOCON doc.

[t-bast]

Indeed, I see the disabled one as an example on how to explicitly disable other features that are enabled by default.

Got it, that makes sense.

I bet new features will be forgotten...

Clearly :), but it's not an issue! We can add them when we realize we forgot some. I still think it's slightly better for users to have them all listed here, they clearly see what's disabled by default (experimental or obsolete).

The more I think about it, the more I think we should just rely on the null trick

Meh. I prefer explicitly disabling stuff! It would be a problem if we had like 100 features, but given our rate of adding new feature bits we should be ok :)

[pm47]

Fair enough, done in deca797.

[t-bast]

💯