feat(rocks): Refactor `on_pull_request` workflows

[orfeas-k]

This PR refactors on_pull_request-related workflows for our ROCKs CI. It mainly introduces new smaller workflows that are then called as jobs in bigger ones. This is heavily based on what telco team is doing in their ROCKs CI.

• Add publish-rock.yaml workflow
• Add integration-test-rock.yaml workflow
• Add sanity-test-rock.yaml workflow
• Add scan-rock.yaml workflow
• Add build-rock.yaml workflow
• rename build-scan-test to build-scan-test-publish.yaml
• Make publish-rock.yaml check if Docker image exists
• Rename to get-rocks-modified.yaml (replace _ with -)
• Rename to get-rocks-modified-and-build-scan-test-publish.yaml (replace _ with -)
• Rename build-scan-and-test-rock.yaml to build-scan-test-publish-rock.yaml
• Refactor build-scan-test-publish-rock.yaml to call reusable WFs
• Refactor build_and_publish_rock.yaml to call reusable WFs
• Add python-version as input to integration-test WF

Notes

• Example run here.
• You can view a successful run here.
• After merged, we will need to update seldonio-rocks ci.
• Publish job fails because image already exists

Python version

(copied from https://github.com/canonical/charmed-kubeflow-workflows/pull/36#issuecomment-1850337611) While triggering this workflow in seldonio-rocks repo, I noticed that integration tests may not be able to run when using Python 3.10 version as also mentioned https://github.com/canonical/katib-operators/issues/139. Thus, I added an input python-version in integration tests workflow which corresponds to which version we want to run our tests with.

• Example run without a python-version input (uses machine installed version)
• Example run with python-version: 3.8 input

In both of those example runs, I enabled publish on_pull_request while we have agreed to turn it off and keep it only for on_push events. We will not have to do this the above and https://github.com/canonical/bundle-kubeflow/issues/761 is resolved. It's the same reason we have a Setup Python 3.8 step in our bundle-kubeflow tests.

Refs https://github.com/canonical/charmed-kubeflow-workflows/issues/31 Closes https://github.com/canonical/charmed-kubeflow-workflows/issues/28 Closes https://github.com/canonical/charmed-kubeflow-workflows/issues/32 Closes https://github.com/canonical/charmed-kubeflow-workflows/issues/35

Issues that were raised during but not tackled by this PR

• https://github.com/canonical/bundle-kubeflow/issues/785
• https://github.com/canonical/charmed-kubeflow-workflows/issues/29
• https://github.com/canonical/bundle-kubeflow/issues/763

[orfeas-k]

While triggering this workflow in seldonio-rocks repo, I noticed that integration tests may not be able to run when using Python 3.10 version as also mentioned https://github.com/canonical/katib-operators/issues/139. Thus, I added an input python-version in integration tests workflow which corresponds to which version we want to run our tests with.

• Example run without a python-version input (uses machine installed version)
• Example run with python-version: 3.8 input

We will not have to do this the above and https://github.com/canonical/bundle-kubeflow/issues/761 is resolved. It's the same reason we have a Setup Python 3.8 step in our bundle-kubeflow tests.