Introduce user-defined wrapdb mirror

[klokik]

This consolidates all queries to the wrapdb to go through the open_wrapdburl() function. The function handles a domain-specific url scheme wrapdb. When encountered, it substitutes the scheme with https and an authority(netloc) with either upstream wrapdb address or a user-defined one from the MESON_WRAPDB_MIRROR environment variable.

Justification:

• wrapdb servers may not always be available
• internal organization policies prohibit using external sources during the build process
• wraps for non-public proprietary subprojects

[jpakkane]

user-defined one from the MESON_WRAPDB_MIRROR environment variable.

This has the potential to be a really nasty way of hijacking user queries for malware injection. Not to mention all the other ways in which environment variables are terrible for storing persistent configuration.

[klokik]

@jpakkane you mean adding more malware, once attacker already gained control over the users shell environment? Or getting the first handful of malware by user getting source code from the untrustworthy mirror?

I'd be glad to hear for alternative more secure options. Providing the mirror address as a meson wrap command argument on each invocation would be acceptable for me, but less convenient in day-to-day use.
Other than that meson does not seem to use any persistent configuration. This does not belong to the machine files either.
How about a meson wrap set-mirror (address) that will be stored in the subprojects dir, along the local version of db?

Getting code from untrusted sources IMO is a user problem. I honestly don't expect anyone to use random third party mirror found on the search engine.

[klokik]

Ok, I can see this being abused on a build machine, as a stepping ladder of a more complex attack.What's worse - it will affect users that are not aware of this variable.