Openvpn compression and proxy support

[stoutes]

Summary

Part of #288, closes #292, closes #299.

Adds OpenVPN compression and proxy support to the builder layer, including
the build_openvpn_connection() function and all supporting types.

Changes

api/models/vpn.rs

• Added OpenVpnCompression enum mapping to NM compress and comp-lzo keys
  • Lzo marked #[deprecated] — comp-lzo is deprecated upstream in favour of compress
  • All compression variants except No carry VORACLE vulnerability warnings in their doc comments
• Added OpenVpnProxy enum with Http and Socks variants mapping to NM proxy keys
• Added OpenVpnConfig struct with builder methods for port, compression, proxy, DNS, and UUID
• All three types exported via pub use vpn::* in api/models/mod.rs and re-exported at crate root in lib.rs

api/builders/vpn.rs

• Added build_openvpn_connection() — builds a complete NM settings dict for OpenVPN
  • connection.type = "vpn", vpn.service-type = "org.freedesktop.NetworkManager.openvpn"
  • All config serialized into flat vpn.data as Vec<(String, String)>
  • Compression dispatches on OpenVpnCompression variants to correct NM keys
  • Proxy dispatches on OpenVpnProxy variants, validates port is non-zero
  • #[allow(deprecated)] on the Lzo arm inside the builder so the function itself doesn't warn
• Added 14 unit tests covering:
  • Basic connection structure (type, service-type, sections present)
  • All 5 compression modes
  • HTTP proxy with and without credentials
  • SOCKS proxy
  • Zero port rejection for both proxy types
  • Port, DNS, and empty remote validation

Notes

• build_openvpn_connection is wired into core/vpn.rs dispatch but the OpenVpn arm in
  connect_vpn currently returns VpnFailed("not yet implemented") until the full
  connect flow from openvpn support #288 lands.

[cachebag]

@stoutes
Will TAL tomorrow. Make sure you rebase off of dev-ovpn, I just merged in our .ovpn recursive descent parser in #314 as well as #309.

I'd presume the builder should/would mesh with that in some way. We'd want to reconcile the approach we made in #309 for OpenVpnConfig as well with the version you created.

Please also update your PR description as well to mention the issues you tackled directly. It looks like you're doing both #292 and #299. In the future, I'd prefer you keep a PR to one issue, unless they're related in some fashion. (#288 is just the tracking issue for OpenVPN support so I wouldn't call them related).

Lastly, HUGE nitpick, but your commit messages should be feat(#<ISSUE_NUMBER>) or feat(nmrs). We don't use lib or the verbose feature.