fix(verify): use container name from configuration in verify tests

[idsulik]

Fixes: #9747

Description
Add using container name from configuration in verify tests

[katiexzhang]

Thanks for the PR, I tested it locally and it seems to be working.

It looks like an integration test is failing however.

[katiexzhang]

It looks like container name is required for verify actually, so this would solve the problem completely.

Something else to consider - wdyt about extracting the name checking logic in getContainerName to run in the s.Go()? If we check the container name existence every time before createAndRunContainer is called, then it should be creating the new ones with diff UUIDs.

[idsulik]

It looks like container name is required for verify actually, so this would solve the problem completely.

Something else to consider - wdyt about extracting the name checking logic in getContainerName to run in the s.Go()? If we check the container name existence every time before createAndRunContainer is called, then it should be creating the new ones with diff UUIDs.

I think it's also a good solution, it'll reduce a bit the execution speed, because you have to call the docker client in sync mode multiple times, but I think it should be okay, because it shouldn't take a lot of time and it'll make sense if a user has tons of containers. And, I think it'll be better to extract the getContainerName func into separate package and start reusing the logic instead of having two almost similar functions in task/verify (for some reason the containerName in the task.go doesn't generate name until it finds free name, it just makes 2 attempts - one with image name and with image name + uuid's part)

[katiexzhang]

I'm going to merge this PR for now + create another issue to unify the verify + custom actions logic. I'm still not sure exactly why everything is working for custom actions (likely has to do with how it gets called + the threads start running), so refactoring might be more complicated than anticipated.