Update FoD scan status polling to use internal REST API

[kadraman]

The current implementation of FoD API has intermittent failure if polling status of scan via id for first few seconds/minutes (see #500). The FoD API plugins use an "internal" REST API to retrieve the scan status as follows:

 /api/v3/releases/RELEASE_ID/scans/SCAN_ID/polling-summary

We should update wait-for commands to use this internal API and re-test to see if this is a better solution.

[kadraman]

Since this API needs both a Scan and Release Id to work we cannot update wait-for commands as is because they have no release context. For example we could implement:

fcli fod sast-scan wait-for 12345 **--release 56789**

but this API is only really designed for one scan id, for multiple scans the API would need to called multiple times!

The response from this API also has different names, e.g.:

[ {
  "ScanId" : 10322560,
  "OpenSourceScanId" : null,
  "TenantId" : 2935,
  "AnalysisStatusId" : 2,
  "OpenSourceStatusId" : 0,
  "AnalysisStatusTypeValue" : "Completed",
  "AnalysisStatusReasonId" : null,
  "AnalysisStatusReason" : "",
  "AnalysisStatusReasonNotes" : null,
  "IssueCountCritical" : 45,
  "IssueCountHigh" : 76,
  "IssueCountMedium" : 34,
  "IssueCountLow" : 19,
  "PassFailStatus" : false,
  "PassFailReasonType" : null,
  "PauseDetails" : null,
  "ScanType" : 2
} ]

In this analysisStatusType is now AnalysisStatusTypeValue!

[rsenden]

Thanks for looking into this. It's unfortunate that this endpoint also requires release id, maybe we should ask FoD team why there's no /api/v3/scans/<scan-id>/polling-summary? (I tried but doesn't exist 😉)

For the time being, maybe we could:

• Have the scan start/list/get/... commands return a new field releaseAndScanId (or similar) that contains <release id>:<scan id>
• Change @DefaultVariablePropertyName("scanId") to @DefaultVariablePropertyName("releaseAndScanId")
• Have all fcli scan-related commands accept <release id>:<scan id> as input (but also still support plain <scan id>)
• If the wait-for command receives only a scan id, use the endpoint that we're currently using
• If the wait-for command receives both release id and scan id, use the polling-summary endpoint
• Use record transformers or other approach to modify the output of the polling-summary endpoint to match the output of the regular summary endpoint

Do you think this would work? Please let me know if you need any assistance/updates to the generic wait-for framework to support this use case.