The endpoint field in the info payload is intended to help the
javascript web code find out where the API endpoint is, and to allow
people who are deploying html/js as static assets to an external web
server drop a json file in that deployment to tell it where their
zuul-web server is.
The only scenario where the endpoint information as served by the /info
or /{tenant}/info endpoints of zuul-web is useful is
same-host/single-apache deployments that are hosted on a sub-url ... and
unfortunately, it's not possible for the aiohttp code to be aware of
such suburl deployments from http headers. request.url has the actual
location (such as http://localhost:8080/info) and X-Forwarded-Host will
only contain the host, not the path.
The actual important aspects of the payload are:
* A payload always be able to be found no matter the deployment
scenario.
* That a deployer can communicate to the javascript code the root of the
REST API in the scenarios where relative paths will resolve to the
incorrect thing.
With that in mind, change the Info.endpoint field returned by zuul-web
to default to None (or actually json null), or to a value provided by
the deployer in the zuul.conf file similar to websocket_url.
This way the web app can view 'null' as meaning "I'm deployed in such a
manner that relative paths are the correct thing to fetch from" and a value
as "the deployer has told me explicitly where to fetch from, I will join
my relative paths to the value first."
Because it is a value that is provided by the deployer if it is to
exist, rename it to "rest_api_url" to better match websocket_url and
stats_url.
Change-Id: I6b85a93db6c70c997bbff1329373fbfc2d1007c6
f93c2fb5f1