Field audit_request_effective_user is not available in SSL_EXCEPTION (TRANSPORT/REST) and BAD_HEADERS (REST) scenarios.

What is the bug?
Currently audit logs within OpenSearch lack the inclusion of the "audit_request_effective_user" field for certain audit categories. Presently, this field is not populated in below categories, leading to incomplete information within the audit logs.
"audit_request_effective_user" is not available in SSL_EXCEPTION (TRANSPORT/REST) and BAD_HEADERS (REST) scenarios.

How can one reproduce the bug?
Steps to reproduce the behavior:

1. Install Opensearch with security plugin and audit logging enabled.
2. After the cluster is ready (healthy), execute the below mentioned delete index API operation without disabling certificate verification.

curl -u admin:admin -XDELETE https://10.254.117.29:9200/akhj
Audit log received:
{
    "audit_node_id": "lVtsxueyTi6p6JsRRxG0ng",
    "audit_request_layer": "REST",
    "audit_request_exception_stacktrace": "javax.net.ssl.SSLHandshakeException: Received fatal alert: unknown_ca\n",
    "@timestamp": "2024-01-29T20:23:43.756+00:00",
    "audit_cluster_name": "viv1-enhan",
    "audit_format_version": 4,
    "audit_node_host_address": "192.168.111.248",
    "audit_node_name": "opensearch-client-7dcd5d7966-56z5p",
    "audit_category": "SSL_EXCEPTION",
    "audit_request_origin": "REST",
    "audit_node_host_name": "192.168.111.248"
}

4. See audit_request_effective_user field is not present containing the username "admin".

What is the expected behavior?
"audit_request_effective_user" field across all audit categories to ensure comprehensive audit logging. This addition will enhance the completeness and utility of the audit logs, providing valuable insights into user actions and interactions with the system.

What is your host/environment?

• OS: Windows 10
• Version 2.11.0
• Plugins

Start by reproducing the SSL_EXCEPTION (TRANSPORT/REST) and BAD_HEADERS (REST) cases with audit logging enabled, then trace the security plugin's audit event handling for those scenarios. Done means audit logs for these cases include audit_request_effective_user with the authenticated username, with corresponding coverage added where the project’s existing audit tests belong.