[ResponseOps][Actions] date validations fail for epoch time values passed as strings

[pmuellr]

In some of our connectors, including PagerDuty, we have parameters whose values are supposed to be dates. Typically we try to parse these with either new Date() or moment() (moment is slightly more lenient). In theory, these should handle epoch date formats - number of millis since 1/1/1970 (or whatever).

In practice, they do not though. Since all parameters are "string-ized", the values sent to the validators are the string values of the number, instead of the number itself. For example, "42" instead of 42.

And it turns out neither Date nor moment handle these. And it turns out, dates in ES are often made available to us as epoch values.

What we should do is create a little utility function that can be reused by connectors, to take a string version of a date, and return a string | number. We'd try to parse the string as a number - integer or float, not sure - and if it's a valid number, return that. Otherwise return the original string. We'd then pass THAT value to the validators, not the original string.

For instance, this is the location in the PagerDuty connector that's affected: https://github.com/elastic/kibana/blob/d92191798a09e4800c5bf87d90e78ee09b49a25f/x-pack/plugins/stack_connectors/server/connector_types/pagerduty/index.ts#L112-L123

This also affects the FormatDate lambda, which can be used by any connector. https://github.com/elastic/kibana/blob/d92191798a09e4800c5bf87d90e78ee09b49a25f/x-pack/plugins/actions/server/lib/mustache_lambdas.ts#L85-L87

We should do an inventory of the connectors and see if there are other date validators that will need this change.

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)