Improve deprecation and version standards

[miguelsantosalvarez]

Description

When mappings are changed from one version to the other we are not being compliant with the deprecation rules we apply to any other component inside Elastic.
Names of the fields and types are being changed with no compatibility backwards within same major version. In consequence, our users can get blind (and can I confirm they do) on their own Dashboards built around the previous mapping after upgrading an Integration.

Putting Crowdstrike as an example, after moving from 1.11 to 1.39 a user lost all their operational visibility. Changelog was there but it is not user friendly to follow, as the details of the changes are just inside the pull requests.

Solutions proposed

Keep compatibility within same major version of the Integration:

• aliasing previous field names is possible
• if the type changes it is possible to use copy_to
• in other case consider this change a major breaking change and increase the major version of the Integration
• add tests for future release with present and past data

Track

Tagging @lucabelluccini to keep track of this issue
It might be related to elastic/elastic-package#579