[CLI] Consistent config/flag parsing & common helpers

[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, only once "in review")

---

Description

I discovered some inconsistencies in how/whether we parse the config in different subcommands.

There was also some code that turns out to be common between some existing commands and the ones I'm adding for #730.

Issue

Related:

• [P2P] Peer discovery debug CLI sub-commands #730

Dependents:

• [P2P] [Tooling] Peer discovery peer list subcommand #892
• [P2P] [Tooling] Peer discovery peer connections subcommand #801

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

• simplified debug message broadcasting by using the p2p modules broadcast method
• factored out common CLI helper functions
  • FetchPeerstore()
  • GetBusFromCmd()
• ensured config and flag parsing is consistent
• ensured a consistent identity across subsequent usages of the debug CLI

Testing

• make develop_test; if any code changes were made
• make test_e2e on k8s LocalNet; if any code changes were made
• e2e-devnet-test passes tests on DevNet; if any code was changed
• 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)

[Olshansk]

Suggested change

	// TODO_THIS_COMMIT: add godoc comment explaining what this **is** and **is not**
	// TODO_IN_THIS_COMMIT: add godoc comment explaining what this **is** and **is not**

OPTIONAL: Update build/linters/blockers.go so we capture other regexes as well

[h5law]

Added a comment here to capture the meaning of the var

[Olshansk]

Things have definitely changed/evolved so I'll provide some context & pointers, but would like to get your thoughts/ideas on what the right thing to do is.

For example, take this target to send a tx:

.PHONY: send_local_tx
send_local_tx: ## A hardcoded send tx to make LocalNet debugging easier
	go run -tags=debug app/client/*.go Account Send --non_interactive 00104055c00bed7c983a48aac7dc6335d7c607a7 00204737d2a165ebe4be3a7d5b0af905b0ea91d8 1000

• We sent it to one address
• That one address adds it to the mempool
• It needs to be gossiped through the network

In utility/utility_message_handler.go, we handle a TxGossip like so where HandleTransaction just adds it to the local mempool.

func (u *utilityModule) HandleUtilityMessage(message *anypb.Any) error {
	switch message.MessageName() {
	case messaging.TxGossipMessageContentType:
		msg, err := codec.GetCodec().FromAny(message)
		// ...
		if txGossipMsg, ok := msg.(*typesUtil.TxGossipMessage); !ok {
			return fmt.Errorf("failed to cast message to UtilityMessage")
		} else if err := u.HandleTransaction(txGossipMsg.Tx); err != nil {
			return err
		}
		// ...
	default:
		return coreTypes.ErrUnknownMessageType(message.MessageName())
	}
	// ...
}

Our goal is: Gossip TxGossip throughout the network
Question: WHat do we change to make it happen? Account Send? s/Send/Broadcast? How we handle case messaging.TxGossipMessageContentType? Wdyt?

[Olshansk]

#810 is done, so are we only waiting on #811?

[Olshansk]

@h5law One tiny lingering comment (going to merge it in myself).

When you squash & merge this to main, make sure to copy-paste your attribution below the message

Co-authored-by: harry <53987565+h5law@users.noreply.github.com>