fix url path inconsistencies

There is a discrepancy between lillypad deployments handling an api.* subdomain menshen listens to and bitmask-core's swagger client which is not aware of the subdomain. Moreover there is a inconsistency between the url pathes of v3 and v5, which we may want to fix (only cosmetic aspect, so lower priority).

Let's look at our current field testing lilypad deployments to illustrate that. The field testing provider serves the APIs at two different base URLs:

• api.ft1.bitmask.net/3/ and api.ft1.bitmask.net:4430/3/ for api v3
• api.ft1.bitmask.net/api/5/ api v5.

First of all current bitmask-core expects the v5 URLs at ft1.bitmask.net/api/5 (no api.* subdomain) , which is why it fails to fetch the configs from apiV5 in a latest lilypad deployment. Also api.<domain>/api looks redundant and is inconsistent with v3.

There are different solutions

A) Make sure v5 is not served at the subdomain api.*

In that case v3 would be served at api.ft1.bitmask.net/3/ while v5 would be served at ft1.bitmask.net/api/5. Changes in Lilypad are required. On the long run we probably can reduce the complexity in Lilypad's ansible roles because creating a subdomain is not required anymore (post v3 deployments). During the transition time we and maybe admins of existing deployments get confused, since we change the URL pattern for the api endpoints. Good documentation is extra important.

B) Adapt swagger configuration and ensure bitmask-core communicates to api.ft1.bitmask.net/5

In that case we don't need to touch lilypad, all changes will happen in menshen's swagger configuration, and another MR in bitmask-core is required to commit the updated generated swagger code. We could remove the duplicated /api/ path, the API change is consistent with the existing api versioning scheme, less people might get confused. However in other deployment scenarios without lilypad, creating an extra api subdomain needs to be handled. Also new deployments likely won't provide apiv3 anymore (in case the client implementation for v5 is stable enough 🤞), so inconsitencies of the api versioning are less of a concern.

I've talked to @sgk, and he thinks solution B is easier to archive after all. I see pros and cons for both options, but the most important point is that we agree on a new api versioning scheme and stick to it. Once APIv5 is public we won't be able to switch it without further disruptions for the client.