It's not being invoked yet, but I've added a placeholder where it's
going.

This is a rough copy/paste, I'll clean up as I flesh out the new tests.

And test it!

* Declares an enum for our types
* Sets type during indicator match rule enrichment
* Sets type during investigation-time enrichment

There are lots of TODOs here, but this implements the following:

* Fetching investigation-time enrichments from the backend
* Parsing existing enrichments from timeline data
* Merging the two enrichment types together, and rendering them in rows
  as specified

Much of the data-fetching is hardcoded, and this broke the existing
pattern with SummaryView/SummaryRow so that got a little messy; I may
end up just using my own EuiTable but we'll see.

Threat Intel tab is currently broken; that's up next.

The investigation-time enrichments are a little messy because they
contain all the non-ECS fields that indicators contain; other than that,
this is looking good.

Still need to add the new header, and potentially sort the fields.

This promotes sanity for the user.

This simply opens the threat intel tab.

This also addresses a bug where we were not properly sorting new
enrichments by first_seen; this is covered under the tests that were
fixed.

Because the enrichment endpoint is dumb and doesn't know about the
existing event or its enrichments, we need to merge these together on
the client to reduce noise and redundant data.

* Massages the response into the format that the inspect component uses
* Moves stateful fetching of query and persisting in redux to new, more
  specialized hook
* Moves existing enrichment hook to a more suitable location in
  containers/

* indicator match rule now specifies `matched.type` as coming from the
  rule
* Inspecting the enrichment query requires use of the redux store, which
  was not previously mocked

This covers the basics of the Alert Summary and Threat Intel tabs; the
investigation-time enrichment functionality is up next.

* Loads more indicators (filebeat data, `threat_indicator2` archive)
  AFTER the rule has executed
* Asserts that those indicators are also found on the alert summary.

This was previously hardcoded during development.

The existing myhash field will generate an alert due to the way the rule
is written, but the alert had no other fields that would match the
investigation time enrichment. This gives it a source.ip, and updates
the indicator to match.

If none of the alert's fields would be relevant to the enrichment query,
then we don't make the request at all.

This field was updated to reflect the source of the match, in this case:
indicator match rules.

If a given field matched multiple indicators, then the previous
contextId was not unique as it was based on field/value that matched.
Adding provider to the mix would fix it, except that we're not
guaranteed to have a provider.

I've added both provider (if present) and an index value to the key to
ensure that it's unique.

This field can never be null, as we always set it in our response.

…onent

These are unlikely to be used elsewhere.

This obviates the need for our filter/guard function and the extra loop
that it entails. We have to specify the return value of our reduce fn,
however, but that's mostly equivalent to our type guard.

This was already partially codified with 'buildEnrichmentId,' which is
used to dedup enrichments; this extends the idea to all fields that
could uniquely identify a given indicator.

This is now used by both the overview card and the enrichment query.

The generic SummaryView component previously had to deal with
multi-valued CTI fields, representing the multiple values coming from
the multiple nested objects with that field.

However, with the new UI we no longer have that constraint, and so the
default columnar style, and the corresponding overriding styles, are no
longer necessary.

The UI does not currently handle these. We need to test the behavior of
long-running queries with this filter, but this should simplify the
behavior to complete/error until we handle partial responses.

Displays a loading spinner in the Threat Intel tab title, and some
loading lines where the enrichments summary is.

This fixes our cypress test, but it's going to start failing again in 30
days. However, by that time I'll have implemented the absolute data
picker, which will allow for a more comprehensive test in addition to us
sidestepping this issue.

The name prop on a Tab will be rendered as a node, so both strings and
elements are acceptable. This relaxes the types to inherit from the
component itself.

The addition of our filtering of the search observable broke this test,
since we now need to implement the search observable.

Rather than do that, we'll instead mock our local hook as that's more
likely to change.

 Conflicts:
	x-pack/plugins/security_solution/cypress/integration/detection_rules/indicator_match_rule.spec.ts

See details on elastic#84020

This override test is failing due to a mapping conflict, which causes
the rule name override field to be invalid and not persisted.

The mapping conflict is due to a typo in the threat_indicator2 archive,
where the document declares one index but the mappings declare another.
While es_archive happily loads the document into the index it specifies,
the mappings already exist via the threat_indicator archive, and thus
the new threat_indicator2 index receives dynamic mappings.

Additionally, because the index created by threat_indicator2 is not the
index specified in threat_indicator2's mappings, the behavior seems to
be to leave that index when calling unload!

Thus, on the next test that cares (override.spec.ts), we have an errant
filebeat (threat_indicator2) index with default mappings, causing
mapping conflicts with our other ECS indexes.