Align input options for --include and --subset arguments

[djptek]

• Have you signed the contributor license agreement? Y
• Have you followed the contributor guidelines? Y
• For proposing substantial changes or additions to the schema, have you reviewed the RFC process? Y
• If submitting code/script changes, have you verified all tests pass locally using make test? Y
• If submitting schema/fields updates, have you generated new artifacts by running make and committed those changes? Y
• Is your pull request against master? Unless there is a good reason otherwise, we prefer pull requests against master and will backport as needed. Y
• Have you added an entry to the CHANGELOG.next.md? Y

Addresses #899

[djptek]

In Draft as need to add tests

[djptek]

low level tests passing, working with include, exclude, subset. next step add higher level tests

[kgeller]

This is more of a tooling addition than a schema change, right?

[djptek]

Indeed, thanks for spotting @kgeller

[kgeller]

Looks great Dominic!

[djptek]

moving back to draft while I create additional tests for --subset

[djptek]

Checked Unit tests and I think coverage is OK, updated documentation to reflect changes from point of view of --subset

[ebeahan]

One small observation, but otherwise LGTM!

Thanks for addressing, @djptek! It'll be nice to have this consistency.

[djptek]

Thanks for review @ebeahan, holding this until new issue #1646 is resolved

[ebeahan]

@djptek, with this change aligning the input behavior of these two arguments, can it be implemented independently from the @timestamp conversation happening in #1646?

[djptek]

@ebeahan I think I need to fix the @timestamp first in order otherwise this PR will permit non-conformant ECS with no @timestamp. I checked the tests and they are valid, it's just a question of order of execution

[ebeahan]

I think I need to fix the @timestamp first in order otherwise this PR will permit non-conformant ECS with no @timestamp

I believe that's already true in the current tooling and not something introduced by these changes?

If this change is ready, we can introduce your improvements here and address #1646 later.

[ebeahan]

@djptek should this one be backported to 8.0?