Confusing behavior related to `max_connections`, `net_read_timeout` and `net_write_timeout` SQL variables in Dolt

Dolt exposes dynamic global system variables for configuring some aspects of the network listener for the server, including `max_connections`, `net_read_timeout` and `net_write_timeout`. However, Dolt does not currently respect those variables for configuring the behavior of the network listener. Users who set them expect them to to take effect, but they don't. They don't even take effect if you `SET @@PERSIST.max_connections` them and then restart the server.

Today, you can set `max_connections` in the listener: stanza of config.yaml and you can set it as a CLI parameter, `--max-connections`. `net_read_timeout` and `net_write_timeout` are only settable through config.yaml, as `read_timeout_millis` and `write_timeout_millis` in the `listener:` stanza.

These variables come from MySQL. For reasons of MySQL compatibility, we probably want them to continue to be writable. At the very least, the currently enforced value should always be read when you read these variables. That means `SET GLOBAL max_connections = 2000;` maybe succeeds, but if it doesn't actually have an effect, an immediate `SHOW VARIABLES LIKE 'max_connections'` should still show `100`, or whatever it is configured at.

It might be reasonable if setting these variables at runtime should take effect, at least for new connections.

It might be reasonable if persisting these variables and having them in persisted state at startup should take effect at server start. What to do when there is conflict between CLI / config.yaml and persisted variables would need to be determined.

It might be reasonable to emit a warning if these variables are set using something like `SET GLOBAL max_connections =` but that statement is going to have no effect.

Our documentation includes a number of examples in the System Variables section where `SET @@PERSIST.max_connections` is explicitly shown. Given how confusing its semantics are currently, we should probably replace those examples with something less likely to cause confusion.