Backport: Add option to use Snyk's per-package endpoint when batching is not available - #7362

…ailable (DependencyTrack#7195)

* Fall back to the Snyk per-package endpoint when the batch endpoint is forbidden

The batch endpoint POST /rest/orgs/{org}/packages/issues is not available to
all Snyk organizations, and answers 403 for those it is not available to.
Since v5 uses it exclusively, and 403 is not retryable, the analyzer fails for
those organizations. The per-package endpoint used by v4 still works with the
same token.

Fall back to the per-package endpoint when the batch endpoint answers 403. The
fallback sticks for the remainder of the analysis, so a single 403 is not
repeated once per batch, and it is logged, because it means one request per
package rather than one per 100.

Fixes DependencyTrack#7137

Signed-off-by: Arjav <arjavdongaonkar@gmail.com>

* Attribute per-package issues by requested PURL and tolerate unknown packages

Two problems with the fallback as first written.

Issues returned by the per-package endpoint were correlated back to their PURL
through SnykModelConverter.getIssuePurl, which reads a fixed representation
index of the batch response shape. A per-package response does not have to
repeat the package coordinates, since the package is implied by the request
URL. When it does not, every issue is skipped and the PURL is then cached as
having no vulnerabilities, which is a silent false negative and worse than the
failure this is meant to fix. The per-package path already knows the PURL it
asked for, so it now keys results by that directly and does not parse
coordinates at all.

A 404 for a package Snyk does not know also failed the whole analysis. The
batch endpoint simply omits such packages, and v4 logged and carried on, so
treat it as having no issues.

The fallback test now uses a per-package response without package coordinates,
so it fails if correlation regresses to reading them.

Signed-off-by: Arjav <arjavdongaonkar@gmail.com>

* Select the Snyk package endpoint by configuration instead of on 403

A 403 can mean things other than the batch endpoint being unavailable, so
inferring the endpoint from it is guesswork. It also wastes a request per
analysis for organizations without batch access, since the first call always
fails before the fallback kicks in.

Replace it with a batchRequestsEnabled setting, defaulting to true so existing
deployments are unaffected. Organizations without batch access turn it off and
the analyzer uses the per-package endpoint directly.

Also lower the per-package request timeout to 10s, since these requests cover
a single package rather than a batch of 100.

Signed-off-by: Arjav <arjavdongaonkar@gmail.com>

* Default batchRequestsEnabled to true in the schema

Setting the default only on the factory's default config covers new
configurations. Configurations already stored in user databases do not have
the field, so they deserialized to false and would have silently stopped using
the batch endpoint on upgrade.

Signed-off-by: Arjav <arjavdongaonkar@gmail.com>

---------

Signed-off-by: Arjav <arjavdongaonkar@gmail.com>
(cherry picked from commit ec415e3)
Signed-off-by: nscuro <nscuro@protonmail.com>