Add support for specifying a constant_keyword value

[andrewkroh]

What does this PR do?

For the constant_keyword field type Elasticsearch allows for the value to be specified in the mapping.
If the value is not specified in the mapping then the value is set based on the first document that is
indexed.

Package data streams will be able to explicitly declare a constant_keyword value and will not have to
include the field with every document sent.

https://www.elastic.co/guide/en/elasticsearch//reference/7.12/keyword.html#constant-keyword-params

Why is it important?

This gives packages more control over constant_keyword field values. It can be used optimize storage for an integration since you could omit the constant_keyword field entirely an event's _source.

Checklist

• I have added test packages to test/packages that prove my change is effective.
• I have added an entry in versions/N/changelog.yml.

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Build Cause: Pull request #194 updated

• Start Time: 2021-06-23T14:15:20.839+0000

• Duration: 3 min 38 sec

• Commit: 5eb3f6e

Trends 🧪

[ruflin]

LGTM

[fearful-symmetry]

Seconding, LGTM

[mtojek]

I see that this is an inconsistency comparing to the original source - ECS repository, which defines it as keyword:

    - name: module
      level: core
      type: keyword
      ignore_above: 1024
      description: 'Name of the module this data is coming from.
        If your monitoring agent supports the concept of modules or plugins to process
        events of a given source (e.g. Apache logs), `event.module` should contain
        the name of this module.'

Do we plan to adjust the ECS schema too (event.module)?

This brings me to the final question - currently the import logic in elastic-package imports fields as they are defined. In this case (event.module) the definition would be altered with local properties (value, type). I'm making sure this is expected behavior.

[andrewkroh]

Do we plan to adjust the ECS schema too (event.module)?

AFAIK there are plans at the moment to change the definition of event.module. But there have been some talks of loosing the specification to allow implementors to use either keyword or constant_keyword.

// fyi: @elastic/ecs

In this case (event.module) the definition would be altered with local properties (value, type). I'm making sure this is expected behavior.

I was expecting that packages would be required to declare their full definition of event.module if they make it a constant_keyword. But for the use-case where the imported definition has constant_keyword but no value I think it should be possible to add a value while also using definition.

[mtojek]

If you prefer you can leave overriding for further improvement (not to block this PR).

[ebeahan]

AFAIK there are plans at the moment to change the definition of event.module.

I've heard some discussion, but I'm not aware of a decision being made yet.

I suggested allowing keyword and constant_keyword to be interchangeable and avoid requiring a specific indexing strategy for all ECS users who wish to use event.module.

[mtojek]

Ship it