While working on implementing proxy support to respect system settings for the Chromium flatpak, I've noticed a few things that are currently missing/not covered by the portal APIs and that could be improved.

Afaics (please correct me if I'm wrong), the current way to use system proxy settings from a portal is through the ProxyResolver portal interface.
The current version of the ProxyResolver interface (v1) only supports one method (GetProxyForURL) and has some limitations:

• No way to check if proxy is enabled in the system, which could be used to avoid invoking the portal to resolve proxies altogether if disabled
• No change notification signal, making it hard to implement a proper cache mechanism client side
• No access to actual settings (enabled/disabled, automatic/manual, pac_url, manual urls, ignore-hosts), forcing the client to use the portal for proxy resolution
• No support to launch the system settings UI and no write access to settings ^

Not having access to the actual settings could arguably be fine, as long as we have a way to reliably implement client caching and to skip the (D-Bus) calls to ProxyResolver.GetProxyForURL altogether when proxy is disabled in the system.

Not being able to launch the system settings UI is also Ok, the client could always rely on the user using the system settings UI directly and simply not support launching it, but that lowers the user experience. For example regular non-flatpak chromium linux builds have a link in its settings to launch the system settings UI, but that just spawns a command directly (e.g. gnome-control-center ... when running on GNOME). There are possible workarounds to make this work, but maybe we should consider an API for it?

With that in mind, I have a few ideas on how to improve here:

1. Add API to access actual settings, with change notification
   • This could be done either as part of the ProxyResolver interface or as a new interface
2. Add a method/property to the ProxyResolver interface to check if proxy is enabled and also a change notification signal trigerred when any of the settings change (including enabled/disabled)

In the chromium case, ideally we would have access to 1) so chromium could use its internal proxy mechanism based on the system settings retrieved using the portal, but 2) would already be a great improvement and allow for a proper cache mechanism and to avoid unnecessary D-Bus calls when the proxy is disabled. We could also provide both worlds, but that may be overkill...

Also worth considering possible privacy concerns if we end up implementing something along the lines of 1) above.

Thoughts?