Set node alias

[enigbe]

What this PR does:

• Adds a function to allow users set the node alias.
• If set, ensures that the provided alias is broadcast with the node announcement

Related issue(s):

• 304

[enigbe]

Thanks! I think beyond checking for the node alias and listening addresses before broadcasting, we should also modify the default_user_config method in Config to, if any of the two are unconfigured:

a) set UserConfig::accept_forwards_to_priv_channels to false b) set ChannelHandshakeConfig::announced_channel to false c) set ChannelHandshakeLimits::force_announced_channel_preference to true

Additionally, we'll want to return an error from connect_open_channel if any of the two are unconfigured and we try to open an announced channel. To this end, it might be bit cleaner if we'd split the method in two (open_channel and open_announced_channel) rather than having it take a simple bool.

TLDR: We should use the configured listening addresses and node alias as indicators whether we are a forwarding node or not. If we're not, we should disallow announced channels.

Let me know if you'd be up for these additional changes, otherwise I'm happy to pick them up as a follow-up.

Thanks for the review. I am happy to keep working on this until it is ready.

[tnull]

Thanks for the review. I am happy to keep working on this until it is ready.

Thanks again! Do you still intend to do this in this PR, or would you prefer we land this and do additional changes in a follow up?

Btw. this also needs a rebase already, and there will be larger code changes upcoming in the LDK/BDK/rust-bitcoin upgrade PR, which will likely also lead to further rebase conflicts.

[enigbe]

Thanks for the review. I am happy to keep working on this until it is ready.

Thanks again! Do you still intend to do this in this PR, or would you prefer we land this and do additional changes in a follow up?

Btw. this also needs a rebase already, and there will be larger code changes upcoming in the LDK/BDK/rust-bitcoin upgrade PR, which will likely also lead to further rebase conflicts.

Apologies for the delay. I am almost done and will be pushing changes today. I'll rebase and get it ready for another look before the end of the day.

[tnull]

Apologies for the delay. I am almost done and will be pushing changes today. I'll rebase and get it ready for another look before the end of the day.

No worries! Cool, thank you!

[enigbe]

Thanks for the review. I am happy to keep working on this until it is ready.

Thanks again! Do you still intend to do this in this PR, or would you prefer we land this and do additional changes in a follow up? Btw. this also needs a rebase already, and there will be larger code changes upcoming in the LDK/BDK/rust-bitcoin upgrade PR, which will likely also lead to further rebase conflicts.

Apologies for the delay. I am almost done and will be pushing changes today. I'll rebase and get it ready for another look before the end of the day.

Hi @tnull, I have rebased and pushed recommended changes. Unfortunately, the integration tests are flaky and I am uncertain about why. Currently investigating.

[enigbe]

Thanks for the review. I am happy to keep working on this until it is ready.

Thanks again! Do you still intend to do this in this PR, or would you prefer we land this and do additional changes in a follow up? Btw. this also needs a rebase already, and there will be larger code changes upcoming in the LDK/BDK/rust-bitcoin upgrade PR, which will likely also lead to further rebase conflicts.

Apologies for the delay. I am almost done and will be pushing changes today. I'll rebase and get it ready for another look before the end of the day.

Hi @tnull, I have rebased and pushed recommended changes. Unfortunately, the integration tests are flaky and I am uncertain about why. Currently investigating.

Hi @tnull, thanks for your review so far. Have you had some time to check out the recent changes I have made? I have addressed the comments raised and would be grateful for any further feedback or recommendation.