feat: expose terminateContainerOnEnd as Cleanup

[hhsnopek]

What does this PR do?

This pull request exposes terminateContainerOnEnd as Cleanup to the package's public API. When utilized in a testing context the utility will call container.Terminate and on error causes the test to fail immediately with the assumption that proceeding with cleanup will cause more issues.

Why is it important?

• Reduction of boilerplate code for users of testcontainers-go
• Encourages cleanup of resources no longer required by a test
  • NOTE: even though moby-ryku handles this, without calling Terminate we could leave the test environment running longer than necessary when waiting for all resources to gracefully exit.

Related issues

None.

[mdelapenya]

I've been thinking about my comment in #569 (comment) twice, where we initially discussed the Cleanup function as part of the public API.

We probably do not need another way to prune container resources, as we already have two methods: Terminate function and Ryuk. Adding a new way to do it could lead to confusion on what to use, being Ryuk the de-facto prune tool that we advocate for (see #566).

we could leave the test environment running longer than necessary when waiting for all resources to gracefully exit

I could agree with this sentence, but I'd need numbers demonstrating that Ryuk could cause an issue waiting for the gracefully exit. AFAIK Ryuk is battle-tested with around a hundred millions of downloads but never heard about that.

On the removal on boilerplate code, when talking about testing, I do prefer being explicit and very possibly repeating code to hiding details that really matter. When removing a container after a test run, I'd like developers to know what to do in a millisecond, without doubt: because Ryuk is de de-facto garbage collector, use it as part of the container request (explicit), on the other hand use the container life cycle function for termination, which is part of the public API for a container, therefore the IDE will help developers in doing so, more than in a helper function exposed at the root package.

I do see the value of that helper function, but maybe not for testcontainers as a library. Hope you understand.

For those reasons, and if you agree, I'd close this issue as not needed, but wanted to check with you first.

[hhsnopek]

@mdelapenya I agree with you on this, I had a similar thought afterward that this really isn't providing much use to consumers. I believe a better implementation of this would Cleanup a container and it's volumes, networks, etc - this implementation won't satisfy that.

Thank you for the response and well-thought review!