Update workflow to rebuild image after Trivy failure

[brucehoff]

When a daily Trivy security scan fails, we want to generate a new patch version (say, advance from 1.1.2 to 1.1.3), build and test that version then, if the new version passes Trivy, publish the Docker image.

Previously the daily scan simply scanned the main Docker tag (which was built from the head of the main branch), but this isn't quite right, since the head of main might be different from the latest tag (1.1.2). So we added the get-image-reference job to trivy_periodic_image_scan.yml to find the latest tag, which we then use to determine what container image to scan.

When a Trivy scan fails we create a new tag. We expected the new tag to kick off a new build, but GitHub does not allow events generated in a workflow to trigger another workflow. (This is to avoid infinite loops.) So we need to explicitly invoke the docker_build_push.yml workflow. To do this we refactored the workflow so that it can be called either by a PR or merge (from the new main.yml entrypoint) or from the trivy_periodic_image_scan.yml entrypoint. Each entrypoint determines (1) what GitHub tag to checkout and (2) what Docker tags to publish to, and passes them along to the docker_build_push.yml workflow.

Before building an image we want to peform static analysis and run unit tests. Since this step must precede the PR/merge-triggered build and the Trivy-triggered image rebuild, we factored it out into test.yml so it can be called both from main.yml and trivy_periodic_image_scan.yml.

[ConsoleCatzirl]

awesome