cli: move the debug code to its respective teams

[knz]

Currently the debug code is strewn across the entire cli package and dilutes its ownership. This incurs two separate problems:

• it makes the cli package hard to explore/understand for newcomers.
• whenever a debug tool needs attention, it is unclear who is the team that should look into it.
• when folk have questions, they don't know who to ask.

To address this, we propose to work as follows:

1. move each debug command to a sub-package clidebug of its respective team home, as described in the table below.
2. in the process of (1), extract bits of common functionality away from the cli package into shared sub-packages too. For example, the RPC client logic would belong to such a sub-package.

Tentative homes:

Owner	Command	Go function	CLI Dependencies
Bulk I/O	backup	ccl.backupCmds	None
Bulk I/O	backup export	ccl.exportDataCmd,	None
Bulk I/O	backup list-backups	ccl.listBackupsCmd,	None
Bulk I/O	backup list-incremental	ccl.listIncrementalCmd,	None
Bulk I/O	backup show	ccl.showCmd,	None
Bulk I/O	job-trace	debugJobTraceFromClusterCmd,	SQL client
KV	raft-log	debugRaftLogCmd,	None
KV	range-data	debugRangeDataCmd,	None
KV	range-descriptors	debugRangeDescriptorsCmd	None
KV	reset-quorum	debugResetQuorumCmd,	RPC client
KV	unsafe-remove-dead-replicas	debugUnsafeRemoveDeadReplicasCmd,	None
SQL Queries	statement-bundle	debugStatementBundleCmd,	None
SQL Queries	statement-bundle recreate	debugBundleRecreateCmd,	SQL client, demo cluster
SQL Schema	doctor	debugDoctorCmd,	None
SQL Schema	doctor examine cluster	doctorExamineCmd	SQL client
SQL Schema	doctor examine zipdir	doctorExamineCmd	None
SQL Schema	doctor recreate cluster	doctorRecreateCmd,	SQL client
SQL Schema	doctor recreate zipdir	doctorRecreateCmd,	None
Server	check-log-config	debugCheckLogConfigCmd,	Log flags
Server	decode-proto	debugDecodeProtoCmd,	None
Server	env	debugEnvCmd,	None
Server	gossip-values	debugGossipValuesCmd,	RPC client
Server	list-files	debugListFilesCmd,	RPC client
Server	merge-logs	debugMergeLogsCmd,	None
Server	zip	debugZipCmd,	RPC client
Storage	ballast	debugBallastCmd,	None
Storage	check-store	debugCheckStoreCmd,	None
Storage	compact	debugCompactCmd,	None
Storage	decode-key	debugDecodeKeyCmd,	None
Storage	decode-value	debugDecodeValueCmd,	None
Storage	encryption-active-key	ccl.encryptionActiveKeyCmd	None
Storage	encryption-status	ccl.encryptionStatusCmd	None
Storage	estimate-gc	debugGCCmd,	None
Storage	keys	debugKeysCmd,	None
Storage	pebble	DebugPebbleCmd,	None
Storage	syncbench	debugSyncBenchCmd,	None
Storage	synctest	debugSyncTestCmd,	None
TBD	tsdump	debugTimeSeriesDumpCmd,	RPC client

Some observations:

• the storage debug commands are standalone and can be migrated without trouble.
• the SQL SChema and Bulk I/O debug commands only require a SQL connection and can be migrated once the SQL conn logic is encapsulated.
• the Server and KV debug commands only require a RPC connection and can be migrated once the RPC conn logic is encapsulated (or, preferably, once we have an alternate mechanism to access the server than RPCs)
• a bit more investigation is needed for the SQL queries statement bundle commands.

Jira issue: CRDB-8989

[knz]

Which metadata would we like to preserve/collect for all debug commands:

• owner team
• whether the command establishes a connection to a server (if yes, how)
• whether the command writes output to disk (i.e. is it safe to experiment)
• what additional data/details to provide when opening a github issue based on that command
• (optional) example use case where the command is useful

[knz]

Pre-analysis on how to move the GRPC client conn code to a sub-package.

Where is it used?

• in the listed debug commands above
• cockroach gen haproxy
• init, quit, node decommission, node recommission

[knz]

Pre-analysis on how to move the SQL client conn code to a sub-package.

Where is it used?

• in the listed debug commands above
• auth-session sub-commands
• import, nodelocal, userfile
• node ls, node status
• sql
• statement-diag

[github-actions[bot]]

We have marked this issue as stale because it has been inactive for 18 months. If this issue is still relevant, removing the stale label or adding a comment will keep it active. Otherwise, we'll close it in 10 days to keep the issue queue tidy. Thank you for your contribution to CockroachDB!