"project update" will always do "Restoring original project mainline states" leading to crash for large projects

[gernot-h]

#116 introduced a side effect. If you call "project update", it will now always update all project mainline states:

> poetry run capycli project update -id 50c... -url https://sw360.siemens.com -t <token> -oa -i project.sbom 

CaPyCli, 2.7.0 - Create or update a project on SW360

Loading SBOM file project.sbom
Updating project...
  3 releases in SBOM
  3 releases in project before update
  3 releases in project after update
  Restoring original project mainline states...

Done

In the current implementation, it will update each release's project mainline state individually. This leads to unnecessary SW360 API calls and for large projects, you will end up with API rate limiting timeouts:

  Restoring original project mainline states...
Traceback (most recent call last):
  File "/root/.cache/pypoetry/virtualenvs/distroclearing-9TtSrW0h-py3.11/lib/python3.11/site-packages/requests/adapters.py", line 667, in send
    resp = conn.urlopen(
           ^^^^^^^^^^^^^
  File "/root/.cache/pypoetry/virtualenvs/distroclearing-9TtSrW0h-py3.11/lib/python3.11/site-packages/urllib3/connectionpool.py", line 897, in urlopen
    return self.urlopen(
           ^^^^^^^^^^^^^
  File "/root/.cache/pypoetry/virtualenvs/distroclearing-9TtSrW0h-py3.11/lib/python3.11/site-packages/urllib3/connectionpool.py", line 897, in urlopen
    return self.urlopen(
           ^^^^^^^^^^^^^
  File "/root/.cache/pypoetry/virtualenvs/distroclearing-9TtSrW0h-py3.11/lib/python3.11/site-packages/urllib3/connectionpool.py", line 897, in urlopen
    return self.urlopen(
           ^^^^^^^^^^^^^
  [Previous line repeated 2 more times]
  File "/root/.cache/pypoetry/virtualenvs/distroclearing-9TtSrW0h-py3.11/lib/python3.11/site-packages/urllib3/connectionpool.py", line 887, in urlopen
    retries = retries.increment(method, url, response=response, _pool=self)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/.cache/pypoetry/virtualenvs/distroclearing-9TtSrW0h-py3.11/lib/python3.11/site-packages/urllib3/util/retry.py", line 594, in increment
    raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='sw360.siemens.com', port=443): Max retries exceeded with url: /resource/api/projects/e4/release/0c (Caused by ResponseError('too many 500 error responses'))

[gernot-h]

I think there are two issues to be addressed here:

• CaPyCli shouldn't do these updates at all for a simple "project update". This code should only run for --copy-from situations
• We should also check if CaPyCli really needs to update project mainline states individually, or if we can't do a batch update for all states in one API call.

[gernot-h]

I was wrong. The project mainline states will always be overwritten with current code when it calls

   def update_project(self, project_id: str, project: Optional[Dict[str, Any]],
                       sbom: Bom, project_info: Dict[str, Any]) -> None:
        """Update an existing project with the given SBOM"""
        [...]
        data = self.bom_to_release_list(sbom)
        pms = self.get_release_project_mainline_states(project)
        try:
            [...]
            result = self.client.update_project_releases(data, project_id, add=self.onlyUpdateProject)  # type: ignore

This will replace existing releases with the list from the SBOM and this SW360 API call will reset all project mainline states.

The problem thus has nothing to do with project copy, it will happen on each project update. So a mechanism to preserve states is actually needed.

It seems there's however a more simple solution: The endpoint api/projects/<id>/releases allows to specify not only a list of releases when updating the project, but also their state (and relation). If we use this variant, we should be able to keep all data when updating.