Add support for geo_shape fields as the entity geospatial field when creating tracking containment alerts

[nreese]

Closes #163996

To test

1. Checkout fake tracks geo_shape branch
2. run npm install
3. run node ./generate_tracks.js
4. in kibana, create tracks* data view
5. create map, use "create index" and draw boundaries that intersect tracks. See screen shot
   
6. create geo containment alert where entity index is tracks* and boundaries index is boundaries.
7. Verify alerts get generated with entity geo_shape locations

[nreese]

@elasticmachine merge upstream

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[nreese]

@elasticmachine merge upstream

[nreese]

@elasticmachine merge upstream

[nickpeihl]

lgtm! just one thing I'm unsure about.

code review and tested with geo_shape faketracks.

[nreese]

@elasticmachine merge upstream

[pmuellr]

Poking around at ZDT/migration issues:

• at first I thought context variable entityLocation was being changed to string | number[], but it appears that's just the internal implementation. Seems like it will always be a string, and the support for existing shapes is the same string. So seems fine. In the future, there will be other "shapes" beyond POINT, like ... SHAPE or something ...
• There is a shape change in x-pack/plugins/stack_alerts/server/rule_types/geo_containment/types.ts, with location widening from number[] to number[] | string. Seems like this is the instance state, persisted In the rule's task document. So in theory, during a ZDT upgrade could have an old Kibana read this, and not expect the string. So feels like we need to model/version this, or whatever. I think this is the first of these we're dealing with!

[nreese]

@pmuellr could you provide some more details around the comment below. What actions need to happen to resolve this?

So feels like we need to model/version this, or whatever. I think this is the first of these we're dealing with!

I could add a new field to store string version. That would keep location the same. Would that be an acceptable solution?

[nreese]

@elasticmachine merge upstream

[pmuellr]

I could add a new field to store string version. That would keep location the same. Would that be an acceptable solution?

That seems like the best solution for now. We're working through how to version this stuff, so that in the future we would know to not run a "upgraded" rule on an "old" kibana, so something like what's in the PR could be made to work, with some version labeling.

The other thought is - how well does old code cope with a string? Worse case is the throws an error, and we may need to do some Dev Console "surgery" to fix it up (probably delete the task document). Maybe that's tolerable?

[nreese]

ZDT addressed with 4ecf124.

new state stored in locationWkt field. Alert executor continues to populate legacy location field with valid data. With these changes, non-updated kibana nodes can handle alert start from updated kibana nodes.

[nreese]

@elasticmachine merge upstream

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: c987849

Failed CI Steps

• FTR Configs #28

Test Failures

• [job] [logs] FTR Configs #28 / console app console autocomplete feature anti-regression watchdogs should activate auto-complete for a single character immediately following a slash in URL

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	15.7MB	15.7MB	+6.4KB
securitySolutionServerless	249.3KB	255.5KB	+6.2KB
stackAlerts	77.2KB	77.2KB	+13.0B
total			+12.7KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
securitySolutionServerless	38.0KB	38.0KB	+2.0B

Unknown metric groups

ESLint disabled line counts

id	before	after	diff
stackAlerts	26	27	+1

Total ESLint disabled count

id	before	after	diff
stackAlerts	26	27	+1

History

• 💔 Build #152843 failed 46be395
• 💔 Build #152502 failed ed4c25b
• 💔 Build #152471 failed d97e6b5
• 💛 Build #152143 was flaky 1df60fc
• 💔 Build #151961 failed d37f7ef

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[pmuellr]

LGTM