fix: Invalid host_permissions should be reported as warning in MV3 and filtered out in MV2

[rpl]

Followup to #3873, Fixes #3888

This PR includes the following changes:

• two new rules code: MANIFEST_HOST_PERMISSIONS (used to report invalid permission as a warning) and MANIFEST_BAD_HOST_PERMISSION (reported as error, only used when a permission doesn't have the expected type string), as the ones we already have for the permissions and optional_permissions manifest keys
• ensure that invalid host_permissions (the ones that are still in the expected string form) are reported as warnings (as we do already for permissions and optional_permissions)
• filter out the additional linting error that the top level anyOf schema entry (recently introduced because of the difference in the schema definition for the "permissions" manifest key in manifest_version 2 and manifest_version 3), because that is redundant (the schema entries nested into it have already reported their validation errors) and it would trigger a JSON_INVALID that is reported as an error even when the nested schema entries reported only warnings
• changes to the tests to properly cover the expected behaviors

As a side note, the ManifestJSONParser's errorLookup method could use a refactoring, it has never been that much readable, but it is also increasing in complexity and it would be good to reorganize it to make it easier to read and maintain over the time, but it may be reasonable to defer that to a separate follow up (e.g. to keep this incremental change to fix the permissions validations smaller).

[willdurand]

Looks good, thanks.

An additional question: should we update the (generated) docs?

[rpl]

Looks good, thanks.

An additional question: should we update the (generated) docs?

@willdurand eh that's a good point, they should... which is making me think: shouldn't we check as part of the CI job that the rules docs are updated with the content of rules.md and there is no pending change that should have been part of the PR?

[willdurand]

@willdurand eh that's a good point, they should... which is making me think: shouldn't we check as part of the CI job that the rules docs are updated with the content of rules.md and there is no pending change that should have been part of the PR?

I thought that was the case already...

[rpl]

@willdurand eh that's a good point, they should... which is making me think: shouldn't we check as part of the CI job that the rules docs are updated with the content of rules.md and there is no pending change that should have been part of the PR?

I thought that was the case already...

Looking to the CI job, that should be the case:

addons-linter/.circleci/config.yml

Lines 106 to 113 in 69a4a95

	npm run build-rules
	# This will return a non-zero exit code if content in the docs/
	# folder has changed. When this fails, run the following command
	# and commit the changes:
	#
	# npm run build-rules
	#
	git diff --name-only --exit-code docs

@willdurand I'll double-check why that step isn't making this PR to fail as we assume it should.

[rpl]

@willdurand eh that's a good point, they should... which is making me think: shouldn't we check as part of the CI job that the rules docs are updated with the content of rules.md and there is no pending change that should have been part of the PR?

I thought that was the case already...

Looking to the CI job, that should be the case:

addons-linter/.circleci/config.yml

Lines 106 to 113 in 69a4a95

	npm run build-rules
	# This will return a non-zero exit code if content in the docs/
	# folder has changed. When this fails, run the following command
	# and commit the changes:
	#
	# npm run build-rules
	#
	git diff --name-only --exit-code docs

@willdurand I'll double-check why that step isn't making this PR to fail as we assume it should.

bah, if I run the job locally (using circleci cli tools and docker) it does fail as expected if changes to docs/index.html were not committed. I'm going to giving another look into why it doesn't seem to fail on circleci as part of the jobs triggered by the pull requests.

[willdurand]

thanks