Tracking upstream issue: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1536

These commits were added to properly support 2FA challenges:

• https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/345bd1b1873124efaf61b650de0dd4c8305a6fe3
• https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/27c701ebfbc95ab9330df128fa6c7a05a4711e34

But they have broken existing configurations, in 2 different ways:

1. Connections created before updating NM and NM-openvpn doesn't work because the connection doesn't have the challenge-response-flags saved to the profile. Thus, NM saves it to the profile and the 2nd time user is not asked for it, and a wrong value is used. This -flags property is only added when the connection is created or modified, but the connections were already working (with some small problems, but working). We shouldn't break existing configurations.
2. Secret agents not using libnm like nm-plasma doesn't understand the new "x-dynamic-challenge" tag used as prefix. Then, the secret is added to the connection as "x-dynamic-challenge:challenge-response", but NM-openvpn expects it to be called "challenge-response" only, so it rejects it. The daemon should be capable to handle this and not breaking compatibility with existing secret agents.