Simplify and deduplicate Jinja2 templates

[Oddly]

The template layer has significant copy-paste duplication and places where Jinja2 is doing work that should live in tasks or vars. Cleaning this up would reduce maintenance surface and prevent the kind of silent divergence that the duplicate logstash_ident bug demonstrates.

Beats output block triplicated (~105 identical lines) — the full ES/Logstash output section with SSL config, the setup.kibana: stanza, and the logging block are copy-pasted across auditbeat.yml.j2, filebeat.yml.j2, and metricbeat.yml.j2. Any SSL option change requires touching three files. This could be factored into a shared include or partial template.

Logstash 8/9 SSL rename repeated 3 times — the ssl => vs ssl_enabled => version branch appears in 10-input.conf.j2 (twice: beats and elastic_agent inputs) and 90-output.conf.j2. Pre-computing the version-specific option names into a vars dict (e.g., _logstash_ssl_enable_key) in tasks would let all three template sites reference a single variable instead of embedding version logic.

Manual list serialization in elasticsearch.yml.j2 — node.roles, discovery.seed_hosts, and cluster.initial_master_nodes are built with manual for-loops and comma handling. These should use | to_json or | to_nice_yaml.

_managed_keys dedup pattern — both elasticsearch.yml.j2 and logstash.yml.j2 implement the same pattern for filtering extra_config keys against already-rendered keys. The pattern works but is duplicated. Also, logstash.yml.j2 does not include xpack.monitoring.allow_legacy_collection in its _managed_keys list, so a user setting it via logstash_extra_config would get duplicate keys.

Template logic that belongs in tasks — the cluster.initial_master_nodes block in elasticsearch.yml.j2 computes cluster bootstrap strategy inline; the sniffOnStart version guard in kibana.yml.j2 makes version compatibility decisions; the verificationMode: certificate localhost special-case in kibana.yml.j2 is undocumented template-side logic. These decisions should be made in tasks via set_fact and the template should just render the result.

Auditbeat module config fully hardcoded — auditbeat.yml.j2 has hardcoded file_integrity paths (/bin, /usr/bin, /sbin, /usr/sbin, /etc), system module datasets, and audit rule files. None of these are driven by variables. The module configuration cannot be customised without editing the template.

Redundant | default() filters in templates — several templates apply | default(5044) or | default(false) on variables that already have defaults defined in defaults/main.yml. Notably, elasticstack_full_stack | default(false) in beat templates contradicts the actual shared role default of true.