Add hit/miss metrics fields for trusted ancestors reporting

[fearful-symmetry]

Change Summary

This adds two custom fields for reporting trusted ancestor lookup hits/misses:

  - Endpoint.metrics.events_cache.trusted_ancestors.hits
  - Endpoint.metrics.events_cache.trusted_ancestors.misses

I've never had to add anything to endpoint-package, so I'm not 100% sure I have everything completed here, even though I've run make clean all.

If you have alternate opinions about how these fields should be named, please tell me, I just came up with these in about 4 seconds.

Sample values

    "events_cache": {
        "trusted_ancestors": {
            "hits": 504,
            "misses": 23578
        }
    },

Release Target

9.x

For mapping changes:

• I ran make after making the schema changes, and committed all changes
• If these field(s) are "exception"-able, I made a companion PR to Kibana adding it (see Readme)
• If this is a metadata change, I also updated both transform destination schemas to match

For Transform changes:

• The new transform successfully starts in Kibana
• The corresponding transform destination schema was updated if necessary

[gabriellandau]

Can you add these fields to the sample metric document for the unit tests?

[pzl]

Change is good, thank you for including values in sample_event.json.

If double is the appropriate data type here, then you are ok to merge

[pzl]

Do we expect these to be decimals? Hits/Misses sounds like a countable whole number thing. Would long, short, integer, unsigned_long be appropriate here?

Quick grep to check what number types we use most commonly, but I didn't look into what any of those fields were (counts of occurrence):

      1    type: float
      2    type: half_float
      7    type: integer
     34    type: double
    122    type: unsigned_long
    332    type: long

[pzl]

@fearful-symmetry I didn't realize auto-merge was on. No worries, but can you still circle back to the data type discussion above?

[fearful-symmetry]

@pzl , yeah, I agree, unsigned_long is probably more appropriate here.