ROX-11356: Update API spec to latest version (3.70.0).

[dhaus67]

Description

Due to an additional field being added within the storageImageNote, Jenkins plugins that were used in combination with 3.70 could not handle the API response, hence the image scan is failing.

This PR will update the API spec to the latest one used, subsequently the client of the plugin, making it compatible with the 3.70 release and forward.

The significant change within this PR is the update of the following:

    storageImageNote:
      type: string
      enum:
        - MISSING_METADATA
        - MISSING_SCAN_DATA
        - MISSING_SIGNATURE
        - MISSING_SIGNATURE_VERIFICATION_DATA
      default: MISSING_METADATA

[janisz]

How about using latest build and run this job nightly to detect similar issues? This can be done in a separate PR

[dhaus67]

Discussed this offline with @janisz and agreed on merging and releasing this PR for now, addressing the nightly run within this ticket: ROX-11371.

[janisz]

When this values are returned? Does user need to manually change something in configuration or it's happens always after upgrade?

[janisz]

Maybe we should use https://openapi-generator.tech/docs/generators/java/#:~:text=enumUnknownDefaultCase

[dhaus67]

Discussed this offline with @janisz , we agreed on creating a new task that will deal with this option and potentially more: ROX-11370.

[rukletsov]

I'm not sure this PR is enough to prevent situations like this one in the future. Ideally, a mere upgrade to some software component shall not break other components, for example, newer versions of Central run fine with older versions of Sensor. I see two possible options:

• a user just updates Central and does not use any new functionality => the jenkins plugin works just fine but might (should?) print a note that not all info from Central can be utilized until after an update;
• a user updates Central and intends to use new functionality, e.g., block unsigned images from being deployed => in that case it is okay and even desirable for the jenkins plugin to stop working and print a clear error.

From what I understand, Image.notes are in the first category and hence an unknown value there shall not considered an error.

[dhaus67]

@rukletsov I agree with the overall sentiment of not requiring the user to update based on new versions of central.
However, I do disagree with the second sentiment, that the user shall not be able to use a policy regarding to image signing / whatever new feature it may be. The Jenkins plugin itself shall act only on the contract of the alert model, irrespective of the policy triggering said alert and its specific implementation. We would only fall in the second case iff we change the alert / API to trigger detections in a non-backwards compatible way.

Regarding ignoring the error explicitly and not fail, @janisz and me have agreed to create ROX-11370 which will cover this, allowing for this fix to be available to customers earlier (there is an issue with the setting that we have mentioned, the Java json decoder/parser currently does not support it).

[dhaus67]

Discussed offline with @rukletsov , will merge this for now under the condition that the created tickets (ROX-11370, ROX-11371) will be done in a timely manner to avoid running into this issue once again.