BOLT 9: Make it clear that 'channel_public' apply to all channels

[pm47]

This follows #109 and Christian's comment in #97.

I have also renamed channel_public to channels_public.

[Roasbeef]

Hmm, why not make this more granular and instead allow nodes to signal their willingness to advertise per-channel?

This route gives nodes more flexibility. With this, nodes don't need to rear down and reestablish a new connection in the case that they want an additional link to another node that has a network visibility policy opposite to that of any prior channels they have open with that node.

[cdecker]

While it surely adds flexibility I don't think we want to add yet another flags field to another message. We're not even sure if people will multiplex channels at all, so adding this here is a bit of an overkill, especially since it can be amended later (featureflag on the connection, signalling that we append a features field to channel_open and channel_accept).

[rustyrussell]

You inverted the bit? I'm confused....

[cdecker]

That's strange indeed, it also clashes with the name for the bits.

[pm47]

Hmmm, I don't know why I did that, how embarrassing! Fixed...

[pm47]

@Roasbeef: the purpose of this PR was just to fix an inconsistency in the spec. I would also prefer to be able to set this parameter at the channel level.

FWIW I see another potential issue with setting it at the connection level: in case of a disconnection, one or both nodes may change their parameter before reconnecting, and it can happen before we finished the channel setup and did/didn't publish the announcements. Which means we probably need to store this parameter at the channel level, and also that we can have both public and private channels in the same connection independently of the current value of the parameter.