move autodiscovery at handler level

[aspacca]

Enhancement

What does this PR do?

Move the integration autodiscovery feature out of the shipper component to the input component: it is now the handler responsible to set an autodiscovery callable to the input

Why is it important?

Moving the autodiscovery feature at the input level make the visibility of the integration scope available early in the code, allowing us to unlock feature like extracting records fields for cloudtrail in the storage, since now it will be possible to know at that point that the content is cloudtrail one

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
  - [ ] I have made corresponding changes to the documentation
  - [ ] I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in CHANGELOG.md

Author's Checklist

• [ ]

How to test this PR locally

Related issues

Use cases

Screenshots

Logs

[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

• Start Time: 2022-04-16T03:30:39.774+0000

• Duration: 19 min 17 sec

Test stats 🧪

Test	Results
Failed	0
Passed	64
Skipped	0
Total	64

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

[aspacca]

/test

[kaiyan-sheng]

I wonder if we should add a log /warning message here to tell user here are the 6 log type we support and the rest goes into generic.

[aspacca]

we could have but not here in my opinion. rather in the elasticsearch sipper: I will do