Add custom URL prefix for HTTP URLs

[rechner]

Hello 👋

A small tweak to the way that URLs for album art is generated for the HTTP RPC server. I utilize the Snapweb interface through a reverse proxy with SSL termination, which unfortunately breaks album art images in snapweb due to port mismatch and SSL mixed content policies (e.g.: my snapserver hosted at snapserver.lan on the default port, is available over the WAN via a reverse proxy at https://snapcast.example.com, but setting http.host = snapcast.example.com results in image URLs being http://snapcast.example.com:1780).

I worry this addition might create some confusion in the configuration with the http.host configuration, but allowing a totally custom URL prefix like this provides better flexibility of schema, hostname, and port instead of using a piecemeal-constructed string, does it make sense to keep both around?

Tested on Debian 11.

Thanks,

---

Pull Request Checklist

• Contributions must be licensed under the GPL-3.0 License

• This project loosely follows the Google C++ Style Guide

• For better compatibility with embedded toolchains, the used C++ standard should be limited to C++17

• Code should be formatted by running make reformat

• Branch from the develop branch and ensure it is up to date with the current develop branch before submitting your pull request. If it doesn't merge cleanly with develop, you may be asked to resolve the conflicts. Pull requests to master will be closed.

• Commits should be as small as possible while ensuring that each commit is correct independently (i.e., each commit should compile and pass tests).

• Pull requests must not contain compiled sources (already set by the default .gitignore) or binary files

• Test your changes as thoroughly as possible before you commit them. Preferably, automate your test by unit/integration tests. If tested manually, provide information about the test scope in the PR description (e.g. “Test passed: Upgrade version from 0.42 to 0.42.23.”).

• Create Work In Progress [WIP] pull requests only if you need clarification or an explicit review before you can continue your work item.

• If your patch is not getting reviewed or you need a specific person to review it, you can @-reply a reviewer asking for a review in the pull request or a comment, or you can ask for a review by contacting us via email.

• Post review:

  • If a review requires you to change your commit(s), please test the changes again.
  • Amend the affected commit(s) and force push onto your branch.
  • Set respective comments in your GitHub review to resolved.
  • Create a general PR comment to notify the reviewers that your amendments are ready for another round of review.

[badaix]

Thanks!
Merged it into the tls branch, because this must be touched in the TLS branch anyways.