Make bootstrap peers consistent across bootstrap and network

[AureliaDolo]

A peer in the bootstrap_peers list in the config is not considered as bootstrap unless it is also marked as bootstrap in peers.json

My idea to tackle that was to have in the GlobalBootstrapState returned by get_state instead of

pub struct GlobalBootstrapState {
    pub peers: Option<BootstrapPeers>,
    ..
}

have something like

pub struct GlobalBootstrapState {
    pub peers: Option<BootstrapPeers>,
    pub bootstrap_peers: Vec<IpAddr>, // peers in the BootstrapSettings.bootstrap_list
    ..
}

or

pub struct GlobalBootstrapState {
    pub peers: Vec<(IpAddr, bool)>, // true if ip in the BootstrapSettings.bootstrap_list
    ..
}

where in network worker

pub struct BootstrapPeers(pub Vec<IpAddr>);

And make sure that these peers are returned even if we don't need to bootstrap.

[AureliaDolo]

I have some preference for the second option

[damip]

Protocol peers are conceptually different from bootstrap nodes, that's why we keep them separate.

A bootstrap node can be bootstrap-only (and not be a protocol peer), can be both on different IPs etc... and a "peer that does bootstrap" can also be there just to seed peer lists without ever doing actual bootstrapping.

To me, this distinction should be kept, and this PR tends to mix things together, reducing flexibility.

[AureliaDolo]

Protocol peers are conceptually different from bootstrap nodes, that's why we keep them separate.

A bootstrap node can be bootstrap-only (and not be a protocol peer), can be both on different IPs etc... and a "peer that does bootstrap" can also be there just to seed peer lists without ever doing actual bootstrapping.

To me, this distinction should be kept, and this PR tends to mix things together, reducing flexibility.

Ok I close