avoid "Restoring original project mainline states" during "project update"

[gernot-h]

This changes the release state handling during "project update". Instead of storing project release states from SW360 and restoring it release by release at the end, we pass on full release data to REST API endpoint for updating linked releases.

As an SBOM has to be provided during "project update" or "project create --copy_from" anyways, we take the release states stored in the SBOM instead of keeping the state in SW360.

Note that this requires also the change from sw360/sw360python#41 for correct "project update" support.

Fixes #121

[tngraf]

Hm, --copy_from does not work any longer:

• yes, the project is successfully copied, including all project mainline states
• But update_project_releases() gets as input a list that does not contain any project mainline states and so all
  existing states are overwritten by OPEN.
• Reason for this is, that the input is created by bom_to_release_list(). This method only knows the SBOM read from file.
  The SBOM file does not contain any mainline state information. How should it - it is an SBOM created by any kind
  of CycloneDX SBOM generator.
• Even calling update_project_releases() with add=True would not help, because bom_to_release_list() returns a list
  of all releases in the SBOM and not of all releases that have changed.

Sorry, this is like the parameter --copy_from would not exist...

[tngraf]

My method get_release_project_mainline_states() extracted the project mainline state out of the existing (=copied) project.
And you removed all this code...

[gernot-h]

Yes, this was by intention and I tried to describe this in my initial comment and that's exactly the point I wanted to discuss with you. ;) Probably I don't completely get your use case.

My assumption was that the SBOM you'll use in --copy-from would be created by CaPyCli from the original project and then be modified as needed by the user - and I also added code to "project createbom" so that created SBOMs now also contain the release-project relation, so that all data is preserved.

I can see your point, but on the other hand, I considered it quite unintuitive, if you pass an SBOM to overwrite the releases during the copy process, that the actual release data would be used from SBOM, but the meta data from the existing project. In general, I wonder if it's a good idea to have --copy-from take an SBOM to modify releases at the same time. Perhaps it would be clearer to have a "just copy" operation, followed by "project update" to modify the releases as needed? And the latter should probably than consider current state plus the information in the SBOM, with clearly described priority, but that's also some work to get the implementation right...

[gernot-h]

@tngraf and me agreed that I will restore the functionality to retain project mainline states and project relations from SW360, but also that the data in the SBOM will have priority if included.

Main intended use case here is to run "project --create --copy-from" with an SBOM created fresh by "capycli getdependencies" or from another scanner which doesn't have the project mainline states included. However, if the SBOM contains these details, we shall use it.

[gernot-h]

@tngraf, I now changed the code as discussed to respect the release states provided in the SBOM and maintaining state from SW360 if SBOM doesn't contain information about it.

So from my side, this can be merged. Please have a look. :)