[lbarrosby]

What this PR does / why we need it:

forwardPlugin in apis/fluentd/v1alpha1/plugins/output/types.go rendered forward.tlsCertLogicalStoreName as:

tls_cert_logical_storeName  Trust

Fluentd's out_forward declares the option as config_param :tls_cert_logical_store_name (lib/fluent/plugin/out_forward.rb). With the camel-cased key Fluentd only logs parameter 'tls_cert_logical_storeName' in <match> is not used and the forwarder keeps the default certificate store, so the CRD field had no effect. It is the only key in the Fluentd plugins that is not snake_case.

The key is now tls_cert_logical_store_name. Nothing else in the rendered config changes.

Note for reviewers: out_forward accepts this option only on Windows and raises This parameter is for only Windows elsewhere. A Linux deployment that sets tlsCertLogicalStoreName today gets a warning and an ignored value; after this change Fluentd rejects that config, which is what upstream Fluentd does with the same setting.

Test: new apis/fluentd/v1alpha1/plugins/output/forward_params_test.go renders a forward output with tlsCertLogicalStoreName: Trust. On master it fails:

tls_cert_logical_store_name = "", want "Trust" in "<match>\n  @id  forward-windows\n  @type  forward\n  tls_cert_logical_storeName  Trust\n  <server>\n ..."

and passes with this change. go test ./apis/... and golangci-lint run ./apis/fluentd/... pass.

Which issue(s) this PR fixes:

None filed.

Does this PR introduced a user-facing change?

Fluentd forward output: `tlsCertLogicalStoreName` is now rendered as `tls_cert_logical_store_name`, the option name out_forward reads.