add VpnDetails enum to VpnConnectionInfo

[cachebag]

part of #288.

changes

add protocol-specific detail reporting when calling get_vpn_info:

#[non_exhaustive]
pub enum VpnDetails {
    WireGuard {
        public_key: Option<String>,
        endpoint: Option<String>,
    },
    OpenVpn {
        remote: String,
        port: u16,
        protocol: String,
        cipher: Option<String>,
        auth: Option<String>,
        compression: Option<String>,
    },
}

add pub details: Option<VpnDetails> to VpnConnectionInfo (non-breaking, struct is #[non_exhaustive]).

populate from vpn.data dict for openvpn, from wireguard section properties for wireguard.

[Dandiggas]

Hey, I'd like to take a crack at this. I'll start with the OpenVPN variant and go from there.

[cachebag]

Hey, I'd like to take a crack at this. I'll start with the OpenVPN variant and go from there.

Thanks!

[Dandiggas]

Hey, after digging into the codebase I noticed this depends on the OpenVPN types from #290 being in place first. Since the VpnConfig trait just landed in #289 , I think #290 is unblocked now — would it be alright if I tackle that one instead? It feels like the right order to build on, and then #301 flows naturally from it.

[cachebag]

Hey, after digging into the codebase I noticed this depends on the OpenVPN types from #290 being in place first. Since the VpnConfig trait just landed in #289 , I think #290 is unblocked now — would it be alright if I tackle that one instead? It feels like the right order to build on, and then #301 flows naturally from it.

Yes, I was just going to ping you. This makes the most sense to me.