Fix Event Threat Detection findings ingestion

[daniel-cit]

What is in this PR:

• ETD Stackdriver parsing for "Bad IP" and "Anomalous IAM grant" updated for the new format of ETD findings in Stackdriver.
• ETD "Bad IP" SCC parsing updated for new finding format in SCC (nested fields instead of flat fields).
• Added SCC Parsing for "ETD Anomalous IAM" grant and "SSH brute force".
• Changed comparison of external users and users in the Policy binding in IAM revoke automation to be case insensitive.
• Updated description of Terraform variable "findings-project" to point the user to the project configured in the Google Cloud Console in "Security" > "Threat Detection"

Observations:

• Stackdriver parsing for "SSH brute force" was not updated because findings in the new format were not found.
• New SCC Parsing for SSH brute force is based in the existing Stackdriver "SSH brute force". Detailed test were added to help future changes if needed.

[daniel-cit]

meta comment - lets really aim for small PRs. so if you have to list 5 or so bullets, probably each bullet should be its own PR. this keeps reviews simple and quick

Hi Tom, good to see you again.

The last two bullets:

• Replacing user == member with strings.EqualFold(user, member) (Moved to PR https://github.com/GoogleCloudPlatform/security-response-automation/pull/191)
• Replacing description = "Project ID where security findings are sent to." with description = "Project ID where Event Threat Detection security findings are sent to by the Security Command Center. Configured in the Google Cloud Console in Security > Threat Detection." (Moved to PR https://github.com/GoogleCloudPlatform/security-response-automation/pull/192)

Are easy to move to two different pull requests, but I don't know which is the best strategy to slice the changes in the parsing of the ETD findings.

We have three findings:

• "Bad IP"
• "Anomalous IAM grant"
• "SSH brute force"

and two formats:

• Stackdriver logs
• SCC Notifications

and their parsing depends on code generated by the protobuf compiler reading from a single file providers/etd/protos/etd.proto which will be a cause of conflict in every PR.

Which would be better in this case?

• 3 pull requests by type of finding
• 2 pull requests by type of format
• 6 pull requests by type of finding x type of format

@tomscript any advice on this ?