Allow comparing connection/child configuration with reported status

[jlearman]

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

We configure Strongswan via golang Vici, for a set of cloud-based network appliances. We periodically audit the configuration to prevent issues caused by ill-advised operator intervention. Unfortunately, the data structures for configuring connections and child SAs are markedly different from the data structures reported when retrieving these. That's a general issue.

My specific issue is checking algorithms, as the namespace for configuration does not match the namespace for reported values.

A discussion (#2044) led to https://github.com/strongswan/strongswan/blob/master/src/libstrongswan/crypto/proposal/proposal_keywords_static.txt, which contains the necessary information, but in a not very useful form.

Describe the solution you'd like

Either
(a) report status using the same form as used for configuration, or
(b) provide utility routines to convert between them or compare them for equivalence.

For (a), it might be ideal to report both the configuration as received plus the status as it is currently reported. This would avoid issues where different configurations can lead to the same status, but also provide a way to verify that the operating configuration is the expected one.
 
I suspect that (b) might lead to problems due to the fact that configurations and statuses are not 1:1.

Describe alternatives you've considered
(1) Using
https://github.com/strongswan/strongswan/blob/master/src/libstrongswan/crypto/proposal/proposal_keywords_static.txt

(2) Restricting the configuration of our component to a specific set of algorithms where we can hard-code the correspondences

Additional context

[jlearman]

I realize this isn't a trivial request.

Incidentally, we started with Libreswan and moved up to Strongswan, which I find superior to Libreswan in every way except this one. While Libreswan reported state in a different structure (text output from whack), the item values used the same format as in the configuration, so doing the audit was cumbersome due to parsing text, but otherwise straightforward. The vici interface is vastly superior, but the change in the format of configurable values is difficult to resolve.