[BUG] Base labels values should probably be string (keyword), not object

[sgryphon]

ECS schema version (e.g. 1.4.0):
1.5.0

ECS .NET assembly version (e.g. 1.4.2):
1.5.0

Elasticsearch version (if applicable):

.NET framework / OS:
Core 3.1 / Linux (or any)

Description of the problem, including expected versus actual behavior:
The Labels property is defined as IDictionary<string, object>, but should probably be IDictionary<string, string>

In the specification / YAML the type of labels is 'object', but I think that refers to the labels item itself, i.e. the dictionary is the object, not the contents.

The text of the specification defines the values as type 'keyword' (i.e string), and specifically states they should not be nested objects. The yaml also has a different property, object_type: keyword, that I think defines the type of the contents.

Allowing objects is obviously cooler, because there is semantic value in distinguishing between "5" and the number 5, etc, but I think the spec is that the values are supposed to be strings.

Steps to reproduce:

1. Add a labels key/value with a scalar, e.g. int, or nested objects:
   logEvent.Labels.Add("Foo", 5);
   logEvent.Labels.Add("bar", new User() { Name = "waz" });

2. See the JSON in Elastic / Kibana
   "labels": {
   "foo": 6,
   "bar": {
   "name": "waz"
   }
   },

[sgryphon]

This is planned for 1.6 release, right?

[russcam]

@sgryphon This is planned for 1.6.

Labels can be any value that can be mapped to keyword:

1. string- including date strings
2. numeric- int, double, long, etc.
3. boolean

A Label type was introduced in the APM agent for this, so that labels is Dictionary<string, Label>. I'm thinking the same approach should be adopted here

[sgryphon]

So in terms of JSON documents I presume "mapped to" means it would be encoded as a string, e.g. {"application": "foo-bar", "env": "production", "someBooleValue": "true", "someNumericValue": "56.789"}

As "true" and "56.789" are valid keywords. Or do you still allow JSON true and 56.789, which would be mapped/normalised to the same keywords, and just not allow sub-objects "someObject": { "a": 1 }

I guess I can just look at the APM agent code, but either way using a specific type, Label, makes a lot of sense to restrict to allowable types.

[russcam]

So in terms of JSON documents I presume "mapped to" means it would be encoded as a string, e.g. {"application": "foo-bar", "env": "production", "someBooleValue": "true", "someNumericValue": "56.789"}
As "true" and "56.789" are valid keywords. Or do you still allow JSON true and 56.789, which would be mapped/normalised to the same keywords, and just not allow sub-objects "someObject": { "a": 1 }

Any of the types in the list in #68 (comment) can be mapped as a keyword verbatim i.e. they don't need to be sent in JSON as string values, but can be sent as their respective JSON type, and with
an explicit keyword mapping applied, would be mapped as a keyword (without an explicit mapping applied, Elasticsearch will default to inferring a mapping from the type).

Having said that, looking at the ECS templates that are included in Elastic.CommonSchema under IndexTemplates, there is only a dynamic template mapping to map strings as keywords

https://github.com/elastic/ecs/blob/557e5df55034ea5beb8431a3537ca383f30f229e/generated/elasticsearch/6/template.json#L12-L20

which means that any label value that isn't a string will not be mapped as keyword and would instead have mapping inferred from the JSON type. I'll raise this with the ECS team. For now, this makes me lean towards mapping as Dictionary<string, string> as all values will map as keyword when the ECS template mapping is used, and serialization of label values will "just work" without requiring any special handling.