Consider removing dependencies on 3rd party APIs for user settings

[thomasneirynck]

Kibana exposes several 3rd party APIs in the settings.

• Date formats:
  • exposed in the advanced settings.
  • Requires formatting using the momentjs pattern language (http://momentjs.com/docs/#/displaying/format/)
• numerical formats:
  • exposed in field formatter settings/advanced settings
  • numeral.js (https:/chjj/marked) pattern syntax (see also Remove external dependency on Numeral.js #8583)
• map zoom levels:
  • exposed in kibana.yml.
  • These are only meaningful for web-maps that use the google-maps tiling scheme supported by Leaflet (Microsoft did nice summary here https://msdn.microsoft.com/en-us/library/bb259689.aspx). These zoom settings will not be meaningful when working with maps in different projections, 3D, ...
• markdown:
  • exposed in visualization
  • relies on marked (https:/chjj/marked), which has known bugs (Markdown box doesn't escape things correctly #4877, Markdown checkboxes not rendering in markdown vis #8024)
  • (that said, markdown is by now a de facto standard, https://tools.ietf.org/html/rfc7763, https://tools.ietf.org/html/rfc7764)

This has some long term maintenance challenges:

• make removal/replacement difficult, as users may depend on quirks/extra features of the library
• may cause breaking changes in Kibana when there are upstream changes.

[spalger]

Interesting replacement for numeral: https:/foretagsplatsen/numbro

[thomasneirynck]

From the discussion on 10/7.

• The goal is not necessarily to ditch 3rd party library, but to document the supported functionality and take ownership of that public specification.
• This should be considered a breaking change.
• Can use numeral.js as a starting point

[thomasneirynck]

cf. #8983: request for feature specifically supported by numeral.js.

[marius-dr]

I encountered another issue in the markdown library:
new lines are now treated differently as opposed to the Github markdown. They now require at least 2 spaces or a \ ending the first line in order for it to be rendered as a Hard Line Break. It's not really a big deal, but seeing as we reference the Github markdown documentation in there, we do have a different behavior than the one in there. Maybe we should be referencing the Commonmark spec that marked seems to be using?