Fix ungraceful shutdown of NGINX

[pleshakov]

To shutdown the IC container, the container runtime sends a signal
to it (SIGTERM by default). The IC handles the SIGTERM signal - after
receiving it, it will gracefully shutdown NGINX and exit.

The termination signal can be customized in the Dockerfile via
STOPSIGNAL. In nginxinc/docker-nginx@3fb70dd
the STOPSIGNAL in the NGINX base images was changed from SIGTERM to
SIGQUIT. Because the IC didn't register a handler for SIGQUIT, the IC
would terminate immediately with a stack dump. As a result, the NGINX
wasn't gracefully shutdown, meaning any inflight requests were aborted.

This commits explicitly configures STOPSIGNAL to SIGTERM in the
Dockerfiles, which overrides any value set in the base images. This
restores graceful shutdown of NGINX.

The bug only affected NGINX images, because NGINX Plus images use
different base images without configured STOPSIGNAL.

while not requred, I added STOPSIGNAL to build/DockerfileWithAppProtectForPlusForOpenShift for consistency

[lucacome]

Wouldn't it be better to handle the SIGQUIT too in the code, so we don't differ too much from the base image?

[pleshakov]

@lucacome since we have control (in the Dockerfile) over what signal is sent to IC, I don't see a point of handling multiple signals, when handling SIGTERM is enough

[lucacome]

You linked a document saying that not every runtime will respect the STOPSIGNAL, I don't see the harm of handling multiple signals directly in the code where we have control over things.

[pleshakov]

@lucacome could you give an example when a runtime will send a SIGQUIT?

[github-actions]

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[pleshakov]

rebased against the master branch

.