More seriously, this step was useful once upon a time because it also used to build the base image for each commit. Now that we have pica-ci-base, this step was only useful to determine what folder have been modified and export some environement variable in a cached file. But Gitlab has race conditions with cache and it will randomly fail, annoying the users of the CI. We will execute the script to set these environment variables at each step of the CI, with a really minimal overhead.

...or clair-whitelist.yml

Also, update some comments.
Line 50: `- "pica-ci-base/**"` changed to `- "pica-ci-base/Dockerfile"` 
in order to match comment

In order to avoid unnecessary pipelines

https://docs.gitlab.com/ce/ci/yaml/#rules

...'build', 'clair' and 'docker-bench-security'

Basically :
- When you push a Dockerfile, all the pipeline will be triggered, except the push-prod stage.
- When you push a docker-compose, only the security checks will be done, based on the latest built image. It is in that case useless to rebuild the image!
- When you push a clair-whitelist, only the Clair stage will be done. Same reason as above.
- When you push something else (e.g. a config file), you may trigger any step you want by hand, for flexibility. No more dumb "Trigger CI" commits!
- When you push something else (not in a pica-* folder), nothing happens and you cannot trigger anything. This is expected.

The pipeline will automatically build the image whenever some files are changed.

But for some tasks, you may want to enable certain stages manually.
This is what this commit does.

Until now, a unique image was built and pushed for each commit, tagged with the commit number.
If this has the avantage to identify which commit corresponds to which image, it causes other problems.

For example, if the pipeline fails because of an approved CVE, you may just want to whitelist the CVE.
Problem : you will need to rebuild the entire image even if nothing has changed, because the "clair" stage tries to pull the image with the current commit id in tag.

So the following was done :
- As soon as an image in successfully built, push it to the registry. OVERWRITE THE OLD IMAGE. This is ok.
- Now, you rebuild the image ONLY if the Dockerfile has changed.
- You run Clair if the clair-whitelist.yml (or Dockerfile, docker-compose) has changed. "clair" stage will be able to find the last previously built image. This is good, no need to build again ! Faster.
- Remove the push-test stage : already done earlier.