[Bug]: Beats Elasticsearch output disables TLS verification and hardcodes the CA path

In all three Beats the output.elasticsearch block hardcodes ssl.verification_mode: none and ssl.certificate_authorities: ["/etc/beats/certs/ca.crt"]. none disables server-certificate verification (no MITM protection), and the fixed path is wrong standalone, where the CA lives under beats_ca_dir (e.g. /opt/ca). The output.logstash block in the same files already uses {{ beats_tls_cacert }}.

Introduce shared Beats SSL settings used by all Beats TLS connections — the Elasticsearch output and the Kibana setup (#514):

• beats_ssl_verification_mode (default full, secure by default). Users can deliberately drop to certificate for SAN mismatches (keeps CA verification, skips the hostname check); none only as an explicit opt-out.
• CA resolution in three branches:
  • full stack → beats_tls_cacert (the stack CA),
  • standalone with beats_ssl_certificate_authorities set → that CA (private / externally-managed backend, CA distributed on the Beats hosts),
  • unset → omit the line → OS system store (public / cloud CAs).

Replaces the hardcoded none + fixed path. If full then fails in a full stack, it reveals a SAN gap in the generated ES certificate that should be fixed.

Locate the three Beats output.elasticsearch blocks and the Kibana setup TLS configuration, then compare them with the output.logstash use of beats_tls_cacert. Implement the shared verification and CA-resolution settings across every Beats TLS connection; done means secure defaults, all three CA branches, and no hardcoded CA path or verification override remain.