Consolidate generated URL information in a single environment variable

[christophermaier]

Cog generates URLs for the API, Trigger, and Services internally, and these URLs may need to be changed depending on how a user deploys Cog. In particular, if Cog is placed behind a proxy, the generated URLs will need to refer to that proxy (and how it is configured), and not how the Cog server itself is configured.

Phoenix Endpoints can be configured specifically for this case (see the documentation on the :url configuration value under Runtime Configuration section). Currently, we supply COG_TRIGGER_URL_HOST and COG_TRIGGER_URL_PORT variables (with corresponding variables for services and the API) to deal with this scenario, but these leave out the :scheme (i.e. https vs http) and :path options, both of which will be needed for properly running Cog in "real" proxied environments.

A realistic proxy example is illustrative:

https://mycog.com:443/v1/.* -> backend:4000
https://mycog.com:443/triggers/.* -> backend:4001
https://mycog.com:443/services/.* -> backend:4002

We could add additional variables for :scheme and :path for each of these endpoints. However, that leaves us with 12 variables that users will have to contend with. Additionally, splitting up the URLs across multiple variables complicates container healthchecking (see e.g. #1156).

Instead, we should accept COG_TRIGGER_URL_BASE (etc.) which encapsulates all the required URL information in a single variable. This will make Cog easier to configure, and will make it easier for us to validate that Cog is set up properly.

These URL_BASE variables are actually already supported in Cog (for triggers and services, at least; one for the API will need to be added); this issue is more about deprecating and phasing out the old, individual variables, and ensuring that the URL_BASE variables are the one true source of this kind of data.

As a result, we cannot simply remove the old variables right now, as this would be a breaking change that would impact current users. We can, however, begin using the new variables in our docker-compose.yml file. The Cog Book should also reflect these changes, and the deprecated nature of the old variables.