[filebeat] Remove old httpjson config implementation

[marc-gr]

What does this PR do?

Removes the original httpjson config implementation

Why is it important?

We do not want to carry deprecated features to 8.0

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.next.asciidoc or CHANGELOG-developer.next.asciidoc.

Relates to #13911

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[mergify]

This pull request does not have a backport label. Could you fix it @marc-gr? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v./d./d./d is the label to automatically backport to the 7./d branch. /d is the digit

NOTE: backport-skip has been added to this pull request.

[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: 2021-10-05T12:19:42.844+0000

• Duration: 105 min 11 sec

• Commit: e9b1c9d

Test stats 🧪

Test	Results
Failed	0
Passed	7677
Skipped	1201
Total	8878

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

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

• /test : Re-trigger the build.

• /package : Generate the packages and run the E2E tests.

• /beats-tester : Run the installation tests with beats-tester.

[leehinman]

So it looks like you can still have config_version in the config file, it just doesn't get parsed. So if someone had a V1 config we would get an error at runtime but not when parsing the configuration file. Is that right?

What do you think about adding

	ConfigVersion string          `config:"config_version"`

to the config struct? Then we could validate with something like:

	if c.ConfigVersion != "" && c.ConfigVersion != "2" {
		return errors.New("config_version can only be 2")
	}

in the validate function.

[leehinman]

So it looks like you can still have config_version in the config file, it just doesn't get parsed. So if someone had a V1 config we would get an error at runtime but not when parsing the configuration file. Is that right?

What do you think about adding

	ConfigVersion string          `config:"config_version"`

to the config struct? Then we could validate with something like:

	if c.ConfigVersion != "" && c.ConfigVersion != "2" {
		return errors.New("config_version can only be 2")
	}

in the validate function.

So I was missing fact that no user should have config_version = 1. Given that, this isn't a valid concern.

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b httpjson-remove-old upstream/httpjson-remove-old
git merge upstream/master
git push upstream httpjson-remove-old