Phase out config server

[monezz]

TODO

[gr-hovest-atb]

For the admin application, it would be quite easy to replace the config server, using custom ygg-admin-[...].yml files for the different profiles (right now there are only a few that are actually in use). They could be combined with environment variables set automatically during deployment.

For the gateways, this will be much more complex, as existing gateways rely on config server to get their config, questions to be discussed:

• how would gateways get their initial config (put it into the JAR? provide it in a start script? ...)?
• where would the current config be centrally stored (in yml files? in a database? ...)?
• how would gateways get config updates (create a new "config refresh API" as it is done for the "api key refresh" mechanism? ...)?

[ChristophBaierATB]

We did not get rid of the config server, yet. It is still required to enable the correct functionality of the Gateways.

[gr-hovest-atb]

The first part of this issue was solved in #158 (remove config server dependency from admin), but the gateway configs still required the config server.

[ChristophBaierATB]

Within the scope of #162 I got rid of the remote BitBucket GitService. Web Application and Config Server exchange proxy configuration files via shared filesystem using a Docker volume instead of git.

@perezdf I think it would make sense to wait until the PR for #162 is merged to continue with this issue as building on that PR would probably ease the process of phasing out the config server.