remove evidence field from CIS GCP

[orouz]

Summary of your changes

this PR removes the result.evidence field from all CIS GCP rules by omitting it from the rego rules. the motivation for this is to reduce raw findings size. regardless, as seen in the changed files, majority of the rules already send the entire resource as the evidence, and since that resource is already available as resource.raw we can just point to it in kibana instead of duplicating it.

findings count and size were checked with:

• POST logs-cloud_security_posture.findings-default/_count
• GET _cat/indices/logs-cloud_security_posture.findings-default?v&h=index,store.size

	before (main)	after
count	1322	1322
size	1126.4kb	914.3kb

this makes the default findings index about 18.83% smaller

Related Issues

• closes https://github.com/elastic/security-team/issues/12315
• related [Cloud Security] use resource.raw as evidence in findings flyout for cis_gcp kibana#227263

[mergify]

This pull request does not have a backport label. Could you fix it @orouz? 🙏
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 8./d branch. /d is the digit
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[orouz]

this is the common theme in this PR - replace generate_result_without_expected with generate_evaluation_result which results in sending an object with just evaluation field instead of a one including evidence too

[uri-weisman]

LGTM 🚀

1. Before merging please verify that this PR didn't change the number of failed/passed findings for the same dataset.
2. Merge is blocked on the corresponding Kibana PR.

[uri-weisman]

@orouz should it be backported to 9.1.0?

[orouz]

@orouz should it be backported to 9.1.0?

generally speaking, yeah. but that's in June 24, which isn't so far from now, and i'm waiting to see the customer feedback before merging this to main or any backports.

[olegsu]

Should also to backport to 9.x?

[uri-weisman]

@olegsu

Should also to backport to 9.x?

We agreed to backport to the next patch versions (8.19.1 and 9.1.1) as we want more time to be assure those changes didn't introduce issues.