Speed up environment teardown by removing docker stop command

What does this MR do and why?

Some low hanging fruit to shave up to 10 seconds per running container in the test teardown phase. On most pipelines this will most likely just be a single container, but on others such as the praefect jobs, we can have 5 gitlab-ee containers running so the issue is amplified further there.

Description:

Using docker stop sends a SIGTERM to the process, which has a default timeout of 10secs (see docker stop --help). If the process doesn't stop within this period, it sends a SIGKILL to terminate the process, so you'll often see that docker stop takes 10 seconds to complete.

eg a recent master build https://gitlab.com/gitlab-org/gitlab-qa-mirror/-/jobs/2392480617#L4351 -- note the 10s lag between the commands.

[date=2022-04-28 21:29:06 from=Gitlab QA] INFO  -- Docker shell command: `docker stop gitlab-gitaly-cluster`
[date=2022-04-28 21:29:16 from=Gitlab QA] INFO  -- Docker shell command: `docker rm -f gitlab-gitaly-cluster`

When testing docker stop --time 60 against our gitlab/gitlab-ee containers, it appears to actually take 10s-15s to gracefully stop the containers so we aren't actually giving enough time to gracefully stop today as it is.

I don't think we have any reason here to worry about gracefully stopping the container, considering the very next step is to run docker rm -f so we can save a little time here across every orchestrated test by bypassing the stop command and just using rm -f directly.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.