SPP check protocol

What does this MR do and why?

Issue: #469161 (closed)

Branched off: !162782 (merged)

Merge with !162782 (merged)

It may be possible to distinguish between user-to-remote pushes (which we want to scan) vs. other workflows including merge trains, mirroring, reverting, etc (which we don't want to scan) based on the gitaly protocol field of the change; during user pushes, the protocol is either http or ssh, while the other workflows' protocol is web. Inconveniently, WebIDE pushes (which we do want to scan) use the web protocol, so we would not be able to limit SPP scanning to http and ssh alone. Ideally, we would be able to use the action field to filter user pushes, but action is currently hardcoded so cannot provide us with useful information. We've asked gitaly and source code to prioritize gitaly#4581 (closed) and #423992.

While we await the delivery of gitaly#4581 (closed) and #423992, we will proceed with the protocol approach in combination with the feature flag. If the feature flag is enabled and the protocol is http or ssh, only scan the diffs; if either the feature flag is not enabled or the protocol is web, scan the entire file. This way, WebIDE pushes are still scanned (albeit with the old behavior where the entire file gets scanned), other web workflows are scanned (with the old behavior), and user pushes over http or ssh use the new diff-scanning method when the feature flag is enabled. This should be sufficient for the GA release until we're able to switch to using action.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.