vpn: handle hint tags in the daemon
Commit 345bd1b1 ('libnmc: fix secrets request on 2nd stage of 2FA authentication') and commit 27c701eb ('libnmc: allow user input in ECHO mode for 2FA challenges') introduced 2 new tags that hints for the secret agents can have as prefix.
These tags were processed (and removed) in the secret agents, not in the daemon. This is wrong because a system with an updated VPN plugin but a not yet updated secret agent (like nm-plasma) will fail: it won't remove the prefix and the daemon will save the secret with the prefix, i.e. "x-dynamic-challenge:challenge-response" instead of just "challenge-response". Then, VPN plugins doesn't recognize it, failing the profile's activation. This is, in fact, an API break.
Also, if the VPN connection already existed before updating NM and the VPN plugin, the secret flags are not added to the profile (they are only added when the profile is created or modified). This causes the user's first time response is saved to the profile, so the activation fails the second and next times.
See:
Anyway, in a good design the daemon should contain almost all the logic and the clients should keep as simple as possible. Fix above's problems by letting the daemon to receive the secret names with the prefix already included. The daemon will strip it and will know what it means.
Note that this is done only in the functions that saves the secrets from the data received via D-Bus. For example, nm_setting_vpn_add_secret doesn't need to do it because this value shouldn't come from VPN plugin's hints.
Fixes: #1536 (closed)
Resolves: https://issues.redhat.com/browse/NMT-1133