[New Platform Migration Phase I]: convert metric vis to vis_type_metric

[lukeelmers]

Summary

The existing metric vis plugin needs to be moved into its own dedicated vis_type_metric plugin that adheres to the new platform plugin structure.

Checklist for creating a new vis type plugin

In most cases, it is recommend to break each of these steps into 3 separate PRs

• 1. Identify all public contracts exposed by the existing service (likely not required for most vis type plugins), and create or update the new plugin to re-export the public contracts. This should be a non-breaking change. Plugin should:
  • Be a directory inside of src/legacy/core_plugins
  • Have a new platform-style plugin definition in typescript, with a setup method returning the public contract (see data plugin as an example). This needs to be exported from the top-level /server and/or /public directory, e.g. export foo = new Plugin.setup()
  • Be broken into logical "services", each with a service definition class
  • Have all static exports done from the top level plugin definition
  • Register the visualization via the "visualizations" plugin's types service.
• 2. Update all downstream modules to import from the new location (likely not required for most vis type plugins). This should be done via relative imports: import { foo } from '../../../core_plugins/foo';
• 3. Move the code from its original location to the new location

Background

Phase I ("Move") consists of consolidating (and in some cases separating) pieces of legacy code into the overall "shape" of the new platform architecture, while still remaining in the legacy world, as legacy plugins, consuming legacy services.

A module is done with Phase I when all of its code has been relocated to the appropriate plugin, with downstream imports for the module being updated to consume it from its new location.

[elasticmachine]

Pinging @elastic/kibana-app