Even when there's no <secret>-flags key for it in vpn-data.

This is essentially to fix regression in the way openconnect uses the VPN
secrets:

Openconnect auth helper is essentially a web browser that fills in an arbitrary
HTML (or XML) form that's used to get the session cookie. The actual secret the
service needs is the cookie itself.

However, what needs to be remembered includes the form data. What data can be
in the form is installation dependent and can not be known in advance. Thus the
flags for it can't be currently set in the connection. The auth helper is not
capable of setting the flags either, because it can only return secrets.

Prior to 1424f249 we treated vpn.secrets without the flags as system secrets
and store them in the connection. Since that commit we just filter them away,
which broke user configurations.

This restores the behavior or treating everyting in vpn.secrets as secrets and
falling back to system secrets.

Another way would be to find a way to flag the secrets, perhaps by
extending the auth helper protocol to be able to store non-secret
properties too.

https://bugzilla.gnome.org/show_bug.cgi?id=768737