server: clarify / improve the TLS join behavior for already-running, not-yet-initialized clusters

[knz]

The new cockroach connect logic and underlying RPCs/APIs cover the following two use cases already:

• the cluster is not yet running. cockroach connect init can set up certificates securely on every server where a node will be running.

• the cluster is already initialized. cockroach connect join can retrieve certificates securely from an already running node. The cluster must be already initialized because the join tokens are stored in a system table.

There is a gap here: what if the cluster is already running, but the cockroach init command has not run yet? With the current interfaces, we cannot add more nodes securely in this case.

There are two solutions for this:

• either tell the operator to shut down the non-initialized nodes, and re-run connect init with the new nodes
• or, revisit the requirement that join tokens must be stored in a system table. Also make it possible to use "transient" (in-RAM only) join tokens on a specific node.

cc @aaron-crl @bdarnell for discussion

Jira issue: CRDB-7353
Epic: CRDB-6663

[bdarnell]

I think I'm fine with saying that you cannot change the membership of a cluster that is not yet initialized. You must wait for initialization before you add new nodes, and in the unlikely event that a node fails during this window, you must wipe and start over.