Add OpenVPN Client proxy option to new "Instances" format

[hllbrg]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [ X ] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [ X ] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

Description:
With the transition from the "Legacy" OpenVPN client configuration to the new "Instances" format, the option to configure a proxy for the OpenVPN client is no longer available. This feature is essential for setups that require proxy connectivity, and its absence can break existing configurations when migrating to the new format.

In restricted network environments, where direct VPN connections are not possible, a proxy is often the only way to establish an OpenVPN connection. Many enterprise and governmental networks enforce strict firewall rules that only allow outbound traffic to specific IPs and Port 443 via a proxy. Without the ability to configure a proxy in the OpenVPN client under the new "Instances" format, users in such environments lose the ability to connect to their VPN infrastructure.

Would it be possible to implement proxy support for OpenVPN clients in the "Instances" format, as it was available in the "Legacy" option? This would ensure that users relying on proxy-based VPN access can continue using OPNsense without breaking their connectivity.

If this feature is not planned to be implemented, could you provide clarification on whether the "Legacy" option has a defined end-of-life (EOL) date? Will it be supported for the next five years, or should users prepare for its deprecation in the near future?

Describe the solution you like

Add the Option for a Proxy back to the UI in the "Instances" format for OpenVPN client configurations.

Describe alternatives you considered

There don't seem to be any other than switching to another solution, but that would require huge amounts of work.

Additional context

No context, but a big "Thank you" for your work on OPNsense and a small disclaimer that english is not my native tongue, but I hope my request is sufficiently described. :-)

[AdSchellevis]

If this feature is not planned to be implemented, could you provide clarification on whether the "Legacy" option has a defined end-of-life (EOL) date? Will it be supported for the next five years, or should users prepare for its deprecation in the near future?

There's no real objection to have the feature, it just costs someone effort for the work, in terms of priorities it's not very high on the list. The first step to deprecate the legacy parts will be to move these to plugins (maybe 25.7, could be 26.1), which effectively means maintenance from our end stops (if it works, fine, when it breaks due to changes elsewhere, you're practically on your own).

No clear date has been set, but I'm quite sure we are not going to stretch these old things for another 5 years.

[tniedermeier]

I understand your approach and that you want to get the legacy code out first. But I want to add a few words to that feature request. We also see demand for this feature especially in OT networks, as @hllbrg already mentioned. OPNsense gets more and more interesting for companies in critical environments and they have very restricted network environments.