Function as though max_local_storage_nodes defaults to 1 in prod mode

[nik9000]

Defaulting max_local_storage_nodes to 50 is useful for testing so
this patch moves that default from "all the time" to "if you don't bind
a public ip". If you do bind a public IP and attempt to use more than
a single node per data directory without explicitly setting
max_local_storage_nodes then Elasticsearch will now fail to start.

Since you can't change the default for a setting depending on the
"prod-mode/non-prod-mode" flag we instead use a sentinel value (0) of
max_local_storage_nodes to mean "user didn't specify, pick it from
the "prod-mode/non-prod-mode" flag".

Since we don't know if we're in prod mode when we pick the data directory
we instead assume that we aren't and then check if the directory that
we picked was OK when we run the BootstrapChecks. The nice thing about
doing it this way is that we warn the user if they have more than one
Elasticsearch in their data directory even if they are running even in dev
mode!

While this is the easiest way to make this change the cost is that, even
if Elasticsearch fails to start because it is in production mode and
max_local_storage_nodes isn't configured it'll still create a directory.

This also removes some of the documentation that suggests you override the
setting on all production clusters. That is no longer important because
Elasticsearch won't start in production mode if you try to start more
than one node.

Closes #19679

[nik9000]

I moved these down below the constants. I thought I was going to add more members so I wanted to fix the order. I didn't end up adding more members but I still like having the members in a sensible order.

[dakrone]

I think this LGTM, but @jasontedor had a comment about adding the parameter feeling out of place, so maybe wait and see if there is further discussion?

[jasontedor]

I have objections to the approach here:

• I do not like that we create the data directory and then later fail the node
• I do not like the handling of the default based on whether or not we are bound or publishing to an external interface
• I do not like the modification to the bootstrap infrastructure just for this one check

I will open a new issue for discussion that relates to this.

[nik9000]

Closing in favor of just defaulting the parameter to 1. That is much less hacky. @jasontedor will open the PR in a bit.

[jasontedor]

I opened #19964.