[chain] Add unconditional_peer_ids to gnoland configuration

[r3v4s]

The less we expose validator node to public, The more safe and sound we can achieve.

Description

Regardless of how many validators we want, its better we hide it from unknown publics and make it does only what validator must do.

One of common ways to do this is using what we called Sentry Node Architecture

Idea is vey simple, validator only talks to sentry nodes and sentry nodes talks to other public nodes. In this circumstance doesn't matter how we configured system, validator must be able to talk to sentry 24/7. For this we need certain option like "ignore any limits, always establish a connection to given peers"

IMHO, it will be perfect if above configuration happens during chain initialization #1886

[moul]

What are the specific tasks to complete?

[zivkovicmilos]

@moul

We sort of have a variation of this functionality through persistent_peers, where we redial (into oblivion, recursivelly) some peers if we lose connections to them (but only if we were connected to them initially, and the connection broke for whatever reason).

gno/tm2/pkg/p2p/switch.go

Lines 311 to 319 in 641d2fd

	if peer.IsPersistent() {
	var addr *NetAddress
	if peer.IsOutbound() { // socket address for outbound peers
	addr = peer.SocketAddr()
	} else { // self-reported address for inbound peers
	addr = peer.NodeInfo().NetAddress
	}
	go sw.reconnectToPeer(addr)
	}

persistent_peers don't actually account for any kind of "slots" on the p2p switch, they live outside of all limitations (max outbound / inbound peers).

What @r3v4s is suggesting is to have a mechanism where we keep the connections to some peers alive at all costs, if they are not existing, given the limitation of persistent_peers I've mentioned above

It should be easy peasy to do when I wrap up #2852, so I'll keep this issue updated 🙏