Feature: anonymous read-only TCP access

### Discussed in https://github.com/influxdata/influxdb/discussions/23229
__Proposal:__
I often use influxdb on IoT devices / sensors to store measurements and query them remotely using grafana with the influxdb datasource, via the influx commandline and via the Python/Golang client libraries.

It would be great to have an option in the influxdb configuration file to restrict a TCP port to read-only access to the database(s), both from a security as a usability viewpoint.

__Current behavior:__
Once the TCP port is available remotely (default setting in Debian), it allows dangerous actions like "drop database", "delete from measurement" and such to everyone that has access to that port (unless credentials are used, which are not enabled by default in e.g. v1.8 that I'm using).

__Desired behavior:__
Add a secondary TCP port (e.g. 8087) that only supports read queries on databases without having to setup credentials. This secondary port may be open on all interfaces by default. The current TCP port (8086) could by default be only bound to the localhost interface.

Programs on the IoT device themselves should still be able to use read/write access to the regular TCP port, so that the measurements can easily be written without having to setup credentials.

An additional authentication/authorization level can be used with e.g. a web proxy, to selectively allow write or read access to a number of these IoT devices using respectively the first (writable) port, or the secondary (read-only) port.

__Alternatives considered:__
Access can of course be restricted using influxdb authentication & authorization. This can however become quite a management pain with hundreds of IoT devices in the field. These credentials have to be available to all the clients that write to the database as well as the remote clients that read from the database. Besides the configuration of the configuration of the credentials in all grafana datasources, client libraries and such, it may also be hard to keep them secret when they are re-used in a number of places.

We could create a proxy-filter that restricts the commands that can be send to the TCP port. This would involve running this filter and exposing only the filtered TCP port. The original port will still be there, and would need to be restricted to the localhost interface.

__Use case:__
* The current default behavior is quite dangerous, once the TCP port is remotely exposed, all users can perform dangerous write actions (unless credentials are used). E.g. on Debian systems, port 8086 is by default open on all network interfaces.
* There are a lot of use-cases where read-only access is enough, e.g. grafana datasources, remotely analysing data, etc.
* fine-grained authorization is very useful on big servers, it can however become quite a management nightmare on a multitude of IoT devices that want to store and make measurements available.

Kind regards,
Dennis

No implementation files, tests, or entry points are named. Start by tracing the configuration and TCP server handling for ports 8086 and the proposed 8087 port, then verify that unauthenticated clients can run read queries while write and destructive queries remain unavailable on the read-only port.

Written by the indexing model from the issue text.