Adopt reconciler logic for orchestrator

[chrisgacsal]

Description

The main purpose for this PR to adopt the reconciler (from the runtime_scan/orchestrator/common package)
based workflow for managing API objects such as ScanConfig, Scan, Target, ScanResult.
This also required to refactor the Provider as all operations must be idempotent as the Scan life-cycle is broken up
into multiple stages where controllers handle a single transition state during a reconciling event.

Orchestrator (and Scanner)

The Orchestrator is responsible for managing controllers for each API object type: ScanConfig, Scan, ScanResult.

ScanConfigWatcher

The ScanConfigWatcher is responsible for scheduling/handling Scans based on ScanConfig.
When the ScanConfig has both the Schedule.operationTime and Schedule.CronLine defined and the latter represents
a single point in time (Quartz), the latter is used for defining the actual operationTime for new Scans.

ScanWatcher

The ScanWatcher periodically polls the API to detect if the Scan objects are scheduled to be run. In case there is
new Scan scheduled, it invokes the Provider to get the Targets in scope. When Targets are available it creates
ScanResult object for each. It monitors in-progress Scans and updates their Summary based on the information
gathered from the corresponding ScanResult objects.

ScanResultWatcher

The ScanResultWatcher monitors the API to find ScanResult objects which are in transient state based on
their status.General.State and resourceCleanup fields. It is responsible for invoking RunTargetScan method of the
Provider in order to set up the scanner instance and start the scan job. The ScanResult is marked as DONE with errors
(it is considered failed) if the Provider was unable to set up the scanner instance due to a permanent error.
It also does perform cleanup of the resources created for scan job by invoking the RemoveTargetScan method of the provider
according to the DeleteJobPolicy configuration.

Provider

Interface

The Provider interface has been split into two (Discoverer and Scanner) in order to separate responsibilities for
discovering scan scopes and actually performing scans.

Both Discoverer and Scanner interfaces have been reworked in order to have better separation of concerns between
the Provider and the caller (Orchestrator), like leaking provider specific data back to the caller.

The new Scanner interface also requires any implementation to be idempotent.

VMClarity-Scanner (aka cli)

The vmclarity-scanner does not have timeout for waiting for volume attachment anymore, instead it monitors
the corresponding ScanResult and raises an error if the state for ScanResult is changed to DONE meaning that
scanning cannot be performed due to external (mostly due to provider) error.

Bugfixes/Improvements

• fix missing /dev mount for vmclarity-scanner container which prevented it to detect when the scanner volume is mounted
• make provider/aws implementation conform with the new Provider interface including the requirement for idempotency

Issues

• Stateful Scan Result state reconciliation #336
• Stateful Scan state reconciliation #335

Type of Change

[x] Bug Fix
[x] New Feature
[ ] Breaking Change
[x] Refactor
[ ] Documentation
[ ] Other (please describe)

Checklist

• I have read the contributing guidelines
• Existing issues have been referenced (where applicable)
• I have verified this change is not present in other open pull requests
• Functionality is documented
• All code style checks pass
• New code contribution is covered by automated tests
• All new and existing tests pass

[ghost]

LGTM, all comments as minor that can be addressed in follow ups. I think the AWS provider can probably be cleaned up a lot now that the interface is simpler (remove all the wrapping interfaces for instance/snapshot etc)