Expose and secure the N+ API for key/value manipulation

[brianehlert]

There are specific use cases where users have specifically asked for a way to securely expose the NGINX Plus API.
The most common use case is manipulation of the key/value store (add, update) or immediate expiration of a token that might be stored in the key/value store.

A key is publishing a specific port in a way that it won't be automatically picked up and automatically exposed by an external loadbalancer. And can be secured in one or more ways.
This should not interfere with the NIC controller processes also using the N+ API for exporting prometheus metrics or upstream group updates.

One dependency that must be completed is: #4668
State sharing / zone_sync has a number of related use cases from global rate limiting, to authentication (token sharing), and arbitrary values.

There should be:

• a default high port and a way for the customer to change it
• default block/allow list behavior. The customer defines the allow list all others blocked. This can be a single or list of ipaddresses or a CIDR. Assume IPv4.
• enabled using either configmap or GlobalConfiguration resource
• exposed through Helm
• this port should not be published to loadbalancer and should always be considered an internal or protected endpoint (we did this with deep service insight)
• this should be default rate limited with the option for the customer to change the value
• this should be method blocked (allowing a customer to make this read only (GET) or read/write (GET/POST))
• state sharing must be enabled for this to make sense.
• this is specific to the presence of NGINX Plus (key/value)
• can some type of authentication be applied? (basic, token, mTLS, APIKey)

Discuss...