[P2P] feat: add background router

[bryanchriswhite]

@Reviewer

This PR may be more digestible / reviewable on a commit-by-commit basis. Commits are organized logically and any given line is only modified in a single commit, with few exceptions*.

*(In the interest of preserving the git-time-continuum 👮🚨, this applies in batches of commits between comments or reviews by humans)

---

Description

Implements a "background router" to work alongside raintree (to be integrated in a future PR) which uses a kademlia DHT for peer discovery and a gossipsub pubsub router for broadcasting and listening.

Issue

Part 1 of #505
Part 1 of #712

Type of change

Please mark the relevant option(s):

• New feature, functionality or library
• Bug fix
• Code health or cleanup
• Major breaking change
• Documentation
• Other

List of changes

• Removed unused Transport interface
• Moved and renamed raintree.RainTreeConfig to util.RouterConfig
• Renamed protocol.DefaultTopicStr to protocol.BackgroundTopicStr
• Added protocol.PeerDiscoveryNamespace
• Added kademlia peer discovery baseline test
• Added background router (kad + gossipsub)
• Renamed P2PConfig#MaxMempoolCount to P2PConfig#MaxNonces
• Renamed DefaultP2PMaxMempoolCount to DefaultP2PMaxNonces
• Updated Dockerfiles using outdated go version to 1.19
• Updated P2P README

Testing

• make develop_test; if any code changes were made
• Docker Compose LocalNet; if any major functionality was changed or introduced
• k8s LocalNet; if any infrastructure or configuration changes were made

Required Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added, or updated, godoc format comments on touched members (see: tip.golang.org/doc/comment)
• I have tested my changes using the available tooling
• I have updated the corresponding CHANGELOG

If Applicable Checklist

• I have updated the corresponding README(s); local and/or global
• I have added tests that prove my fix is effective or that my feature works
• I have added, or updated, mermaid.js diagrams in the corresponding README(s)
• I have added, or updated, documentation and mermaid.js diagrams in shared/docs/* if I updated shared/*README(s)

The check succeeded, dismissing the review comment.

The check succeeded, dismissing the review comment.

[Olshansk]

Just a couple questions but otherwise almost g2g

[Olshansk]

I don't fully understand this. So when would you embed a struct inside of another one?

To me this seems like a worthwhile usecase

[bryanchriswhite]

I'm suggesting never. It doesn't look/feel good from the usage side:

	rtCfg := RainTreeConfig{
		BaseConfig: BaseConfig{
			Host:                  nil,
			Addr:                  nil,
			CurrentHeightProvider: nil,
			PeerstoreProvider:     nil,
		},
		MaxNonces: 100,
	}

Seeing this 👆 makes me want to write a NewRainTreeConfig() function which would be a bit ridiculous IMHO given that that the purpose of the config originally was to simplify the NewRainTreeRouter() function signature.

Additionally, I expect significant simplification may be around the corner for the router interface. I'm anticipating being able to eliminate the need for the background router to hold a reference to either provider (maybe even the pokt addr as well). This would cause further divergence between BackgroundConfig and RainTreeConfig, likely making baseConfig another temporary step.

[bryanchriswhite]

I feel strongly about not taking embedding seriously as an option because of the impact on readability, given the context. An alternative to defining baseConfig would be to duplicate the IsValid() implementation across both RainTreeConfig and BackgroundConfig; however, I see the way it's currently written as a simplification of that.

[Olshansk]