Make the mobileconfig API parameterized and more robust

[ainar-g]

We've already had quite a few bugs about the mobileconfig HTTP API and its autoselection of hostnames. Instead of churning out more temporary solutions, let's solve the issue in a more systematic way in v0.105.0:

(Updated 2020-11-27 after @ameshkov's comments.)

1. The mobileconfig API MUST NOT respond with naked IP addresses or hosts with ports.
2. The client MUST provide the host that is expected in the output XML, for example in a GET query parameter. This allows us to use the API in situations where the server supports several hosts, as well as with client IDs. But if they don't, use tls.server_name, and if it's not set, return a 500 error.
3. The UI MUST NOT show the links to the mobileconfig API unless tls.server_name is set. Perhaps show a form for getting a link with the desired host instead.

Things to think about and figure out:

1. Q: Should we make the tls.server_name parameter required? What about servers that can accept connections targeting multiple hosts?
   A: It is required, but only when clients don't provide a host of their own.
2. Q: Should there be a default host when the client doesn't provide one, or should we be strict and always require one?
   A: The default is tls.server_name.
3. Q: Should we ban GETting the mobileconfig API over plain HTTP?
   A: No, since clients provide the host now.
4. Q: What about wildcard certificates?
   A: If tls.server_name is set, it does not matter what certificate is used. If not, handle this in the UI and ask users to enter the required hostname.

@ameshkov, can you please validate my thoughts here?

[ameshkov]

The mobileconfig API MUST NOT respond with naked IP addresses or hosts with ports.
Should we make the tls.server_name parameter required? What about servers that can accept connections targeting multiple hosts?
Should we ban GETting the mobileconfig API over plain HTTP?

Since it now uses the hostname provided by the client, it does not matter how it was requested.

Should there be a default host when the client doesn't provide one, or should we be strict and always require one?

Yep, if the hostname parameter is empty, we can use config.tls.server_name.
If it's not set either, we should return error 500.

What about wildcard certificates?

If config.tls.server_name is configured, it does not matter what certificate is used.
If it is not configured, we should handle this in the UI and ask the user to enter the desired hostname -- add it to the checklist here: #2075

[ainar-g]

The backend and the documentation are mostly done. @ArtemBaskal, could you please add the frontend logic?

[ainar-g]

I feel like this is done for now. @ameshkov, should we keep this issue open for future improvements, for example multiple hosts support, or should we close this issue for now?

[ameshkov]

@ainar-g nope, let's close it