Enhance Auth Webhook Caching with Configurable Client Headers for Cache Key Formation

### **Description**:

The cache key is determined based on the request body if the feature is turned on, and "client headers," but it doesn't provide specific details on which client headers are used.

**Reference**: https://hasura.io/docs/latest/auth/authentication/webhook/#webhook-auth-caching

Currently, there is no option for configuring custom headers for cache key formation. The following headers are always excluded from cache key formation without any control from the admin:

For POST type webhook, except the following, other headers are involved in the cache key.

```
"Content-Length"
"x-request-id"
"cf-connecting-ip",
"cf-ipcountry",
"cf-ray",
"cf-visitor"
```

For GET type webhook, the aforementioned headers and the following headers are excluded in the cache key.

```
"Content-MD5",
"User-Agent",
"Host",
"Origin",
"Referer",
"Accept",
"Accept-Encoding",
"Accept-Language",
"Accept-Datetime",
"Cache-Control",
"Connection",
"DNT",
"Content-Type"
```

**Proposed Solution**

We would like to propose an enhancement to the auth webhook caching feature. Specifically, it should include a configuration parameter that allows the administrator to set which client headers should be included as part of the cache key. Additionally, in the case of the Cookie header, there should be an ability to list the specific cookies that should be part of the cache key.

**Alternatives**

We have considered building another caching mechanism instead of using this feature. However, having the ability to configure the cache key directly would be a more efficient and integrated solution.

Start with the auth webhook caching behavior described in the referenced documentation: https://hasura.io/docs/latest/auth/authentication/webhook/#webhook-auth-caching. Trace the existing cache-key formation for GET and POST webhooks, then define how administrator-selected headers and selected Cookie values should be configured and applied. Done means the cache key honors those configuration choices, with coverage and documentation for the resulting behavior.

Written by the indexing model from the issue text.