This is a sub-issue of #60632.

We want the start commands to determine their TLS certificate automatically, if given a --num-expected-initial-nodes and --init-token flags.

There are two cases to consider:

• the cluster is not initialized yet. In this case, we want to use the "initial handshake" protocol.
• the cluster is initialized already. In this case, we want to use the "add node" protocol.

What is complicated is that at the moment the process starts, we do not yet know which of the two situations apply. In the base start code, which of the two modes apply is discovered after the the new node has attempted to join another node, and the current cluster status is determined from the other side of the RPC connection.

So we cannot implement the automatic logic in start by just looking at the state of the TLS certificates on disk.
We also need to know whether the rest of the cluster is initialized already or not.

We can do this in either of two ways:

a. either --join mentions other nodes. In that case, we can connect to the other node to see if the cluster is already initialized.

b. --join does not mention other nodes (i.e. the current node is going to be a join target for other nodes). In that case, we don't know whether the rest of the cluster is initialized already until another already-initialized node joins.

It's possible that the second case here is bogus, because of the discussion in #61621.

So let us focus on the first case for a bit. At the moment the process starts, it knows its --join flag already, but not its TLS certificates. So it cannot connect safely to the remote node yet. What can it connect to, to determine node status?

Thanks to #63492, there is a non-authenticated endpoint that could be used for this purpose. The details need to be investigated.

Jira issue: CRDB-6796
Epic: CRDB-6663