Webhook action requires basic authentication credentials

[peterschretlen]

Describe the bug:
The webhook action requires basic authentication credentials user and password in its config schema, even if the endpoint does not support basic authentication.

Steps to reproduce:

Creating a webhook action with no auth credentials returns HTTP 400

 $ curl -s -k  -d '{"name":"dummy webhook", "actionTypeId":".webhook", "config":{"url":"http://127.0.0.1:8000"} }' https://localhost:5601/api/action -Hkbn-xsrf:true -u elastic:changeme -HContent-Type:application/json | jq .
{
  "statusCode": 400,
  "error": "Bad Request",
  "message": "error validating action type secrets: [user]: expected value of type [string] but got [undefined]"
}

Including dummy values for user and password will pass the validation and create the action

$ curl -s -k  -d '{"name":"dummy webhook", "actionTypeId":".webhook", "config":{"url":"http://127.0.0.1:8000"}, "secrets":{"user":"", "password":""} }' https://localhost:5601/api/action -Hkbn-xsrf:true -u elastic:changeme -HContent-Type:application/json | jq .
{
  "id": "b07a2f42-439a-49fb-8a78-79399faf2001",
  "actionTypeId": ".webhook",
  "name": "dummy webhook",
  "config": {
    "url": "http://127.0.0.1:8000",
    "method": "post",
    "headers": null
  }
}

Expected behavior:

1. Basic authentication should not be required. The target service may have no authentication.
2. Ideally other types of authorization header should be allowed ( axios converts the credentials to an Authorization header and will overwrite any other Authorization header being used, and even if we could set them the header values are not encrypted )

Only item 1 is really necessary. 2 is 'nice to have' but not required - for now I think it's acceptable to say we only support basic authentication ( watcher webhooks only support basic auth ).

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[pmuellr]

In support of 2. ^^^ - which is noted as a 'nice to have' - seems like one possibility would be to also support an authorization secret property, in addition to user/password. You could only use one or the other, not both. The authorization secret would be passed directly as the authorization http header. Eg, Bearer token foo-bar-123.

With the idea being these would end up being encrypted.

Without something like that, a customer would have to store the api key in the unencrypted headers properties.

[peterschretlen]

I've logged the second part of this issue ( secret headers and other types of authentication headers) here: #56874