Migrate legacy maps service to NP & update refs

[kindsun]

Migrates the legacy maps service from an angular service in ui/vis to the maps_legacy plugin. This service is a dependency of the Coordinate, Region and Vega maps plugins. This PR accomplishes the following

• Moves the legacy code to the NP, it can be leveraged by plugins as mapsLegacy
• Deangularizes service_settings
• Updates references to the code in Region, Coordinate, Vega Maps
• Updates dependencies, initialized in a local kibana_services file similar to how new Maps is done

A few things to note:

• Where needed, TypeScript definitions were used/updated but it wasn't a primary focus of this PR since this is blocking other work on the other legacy maps plugins
• kibana_map is very nearly a static file that can be provided without any external kibana services, with the exception the notification.toast service leveraged in map_messages. I attempted to supply new instances of kibana_map via a factory function in the plugin > setup method but ran into issues with the Leaflet Draw control that appear to be unrelated to the code changes, and more related to providing Leaflet via an Angular-based pipeline. There were no easy workarounds to make this work as we'd like. For this reason, kibana_map is served as a static file and leveraging plugins can optionally inject the toast service. Since we're only creating KibanaMap instances in 2 places (vega_map_view, base_maps_visualization) and there are no plans to leverage our legacy maps elsewhere, I believe this is the right solution for now.
• getZoomPrecision and getPrecision were broken out into the separate file precision.ts since they were some of the few functions requiring kibana services

Since the legacy maps visualizations are hidden by default in Kibana versions Basic and above (although the sample data includes Region Maps) the best way to test this out is to use Kibana OSS:

• Run ES in oss: yarn es snapshot --license oss
• Run Kibana in oss (there are a few different ways to write this): node scripts/kibana --dev --oss

[elasticmachine]

Pinging @elastic/kibana-gis (Team:Geo)

[kindsun]

retest

[thomasneirynck]

thanks!

I think there's two things to look at:

1. as discussed in person, there seems to be a regression in the display of attribution

Note that this is a limitation of Leaflet-attribution control and requires the raw HTML to display as-is. This seems to escape it first.

2. the x-pack tilemap plugin (kibana/x-pack/legacy/plugins/tilemap) no longer extends the URL-params of the service-settings. This plugin's only purpose is to add a license-key to the URL-params using the ServiceSettings#addQueryParams method (

   kibana/x-pack/legacy/plugins/tilemap/public/vis_type_enhancers/update_tilemap_settings.js

   Lines 21 to 22 in c2c1253

   	serviceSettings.addQueryParams({ license: tileMapPluginInfo.license.uid });
   	serviceSettings.disableZoomMessage();

   ). This plugin likely will need to be migrated as well in this PR to correctly pull the dependency.

[kindsun]

1. as discussed in person, there seems to be a regression in the display of attribution

As we later discussed, I removed sanitation. Since we're in control of the ems-client lib and the calling code, there appear to be no significant associated risks.

1. the x-pack tilemap plugin (kibana/x-pack/legacy/plugins/tilemap) no longer extends the URL-params of the service-settings. This plugin's only purpose is to add a license-key to the URL-params using the ServiceSettings#addQueryParams method (

   kibana/x-pack/legacy/plugins/tilemap/public/vis_type_enhancers/update_tilemap_settings.js

   Lines 21 to 22 in c2c1253

   	serviceSettings.addQueryParams({ license: tileMapPluginInfo.license.uid });
   	serviceSettings.disableZoomMessage();

   
   ). This plugin likely will need to be migrated as well in this PR to correctly pull the dependency.

This plugin should be migrated but we should do that in a separate PR. I've updated #60325 to account for this. I experimented with handling licensing logic in MapsLegacy directly. This seemed to work in Basic but failed in OSS since there's no way to specify a conditional dependency like "only depend on licensing if x-pack is available" in an NP plugin's kibana.json. For now I was able to fix it by obtaining a reference to MapsLegacy via an npSetup import, this works as expected in both OSS and Basic+ and is a good fix until we migrate it.

[elizabetdev]

Just a few SCSS files were moved to a different folder. The changes LGMT! 🎉

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 9cd3949

History

• 💚 Build #39879 succeeded f9a41e9
• 💔 Build #39435 failed a3278ca
• 💔 Build #39322 failed d953423
• 💔 Build #38966 failed fbd967b
• 💔 Build #38921 failed fbd967b

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

[thomasneirynck]

I tested both region and coordinate maps and works!

wrt sanitize removal, is there a possible equivalent already available? (otherwise consider using a regex to parse out href and contents and sanitize separately).

wrt

This plugin should be migrated but we should do that in a separate PR. I've updated #60325 to account for this. I experimented with handling licensing logic in MapsLegacy directly. This seemed to work in Basic but failed in OSS since there's no way to specify a conditional dependency like "only depend on licensing if x-pack is available" in an NP plugin's kibana.json. For now I was able to fix it by obtaining a reference to MapsLegacy via an npSetup import, this works as expected in both OSS and Basic+ and is a good fix until we migrate it.

+1 on doing this in separate PR.

I think we discussed doing this in the Maps plugin. Maps is loaded in basic+ anyway. It'd bloat the purpose of the Maps-plugin a little bit, but a fair trade-off imho if it can remove an entire plugin.

[thomasneirynck]

why are these gone?

[kindsun]

I ran both an i18n check w/ fix flag and an extract. Neither of these indicated anything missing or out of place wrt maps_legacy. i18n did complain a few commits back about adding the new plugin directory, which I did here. It's likely that some translations require manual translation and are flagged in a separate documentation process. Unfortunately it's not as easy as just updating the dot path to its new location since this would just be wiped out by the next node scripts/i18n_extract command someone runs. I did notice when running node scripts/i18n_extract that both of these paths were correctly grabbed for the english (untracked) file here:

So they are tracked correctly and should be translated in a later process

[kindsun]

I think we discussed doing this in the Maps plugin. Maps is loaded in basic+ anyway. It'd bloat the purpose of the Maps-plugin a little bit, but a fair trade-off imho if it can remove an entire plugin.

We did indeed. I keep going back and forth on this but I'm (at least currently) in favor of keeping it as a separate plugin providing data to this new maps_legacy plugin. It feels cleaner to me. That idea needs more fleshing out though since it could have the same issue as trying to handle licensing directly in this plugin (i.e.- works in basic, doesn't work sans x-pack in oss). Definitely happy to chat further separately on this in the context of a future PR!

[kindsun]

wrt sanitize removal, is there a possible equivalent already available? (otherwise consider using a regex to parse out href and contents and sanitize separately).

As discussed offline, tracking this here: #63399