[Alerting UI] Use recorded start/duration/end times from event log for rule details page

[ymao1]

With this PR, we are persisting additional information to the event log about the start, duration and end time of each alert (instance). We should be able to simplify the calculations that are currently being performed to get the start time of active alerts (for duration calculation).

Note:

• While we could use the duration that's now persisted in the event log, that value is updated only when the rule executes so it may be misleading for rules that execute at a longer interval. Probably better to use the recorded start time and calculate the duration to date.
• Whatever changes we make should still work with event log documents written prior to this update.

[elasticmachine]

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

[pmuellr]

I was searching for this issue, couldn't find it, so created another one, which I'll close. But I added some additional detail, so copying that in here:

The calculation of the "alert duration", we are doing today is expensive. The relevant code is in this module: x-pack/plugins/alerting/server/lib/alert_instance_summary_from_event_log.ts which is called from here:

kibana/x-pack/plugins/alerting/server/rules_client/rules_client.ts

Lines 453 to 463 in 946e145

	let events: IEvent[];
	try {
	const queryResults = await eventLogClient.findEventsBySavedObjectIds('alert', [id], {
	page: 1,
	per_page: 10000,
	start: parsedDateStart.toISOString(),
	end: dateNow.toISOString(),
	sort_order: 'desc',
	});
	events = queryResults.data;
	} catch (err) {

Basically, in previous releases, we didn't have the alert duration available directly in active-instance events, so we had to calculate it by finding the closest new-instance event. The date on the new-instance event becomes the activeStartDate in the AlertInstanceStatus:

kibana/x-pack/plugins/alerting/common/alert_instance_summary.ts

Lines 28 to 34 in 946e145

	export interface AlertInstanceStatus {
	status: AlertInstanceStatusValues;
	muted: boolean;
	actionGroupId?: string;
	actionSubgroup?: string;
	activeStartDate?: string;
	}

There were problems with this approach anyway, as the query getting the event log docs may not have gone far enough back to find a relevant new-instance event. But the big win will be not having to return all the event log docs, to get the alert duration, we can just get the last active-instance event, which contains the duration.

Another optimization we could make is to move the alert duration into the task manager state, shape here, since I think we already have to get the task manager state whenever we calculate the alert instance summary:

kibana/x-pack/plugins/alerting/common/alert_instance.ts

Lines 11 to 21 in 946e145

	const metaSchema = t.partial({
	lastScheduledActions: t.intersection([
	t.partial({
	subgroup: t.string,
	}),
	t.type({
	group: t.string,
	date: DateFromString,
	}),
	]),
	});