Implement image pull policies

[thedrow]

These policies exist in testcontainers-java and are currently missing from this project. They allow you to specify when you should pull a new image.

[thedrow]

@tillahoffmann This is ready for review. Do you mind taking a look?

[codecov-commenter]

Codecov Report

Merging #233 (798baa0) into master (95fb5e0) will increase coverage by 0.79%. The diff coverage is 95.12%.

@@            Coverage Diff             @@
##           master     #233      +/-   ##
==========================================
+ Coverage   86.32%   87.12%   +0.79%     
==========================================
  Files          27       33       +6     
  Lines         746      823      +77     
  Branches       70       81      +11     
==========================================
+ Hits          644      717      +73     
- Misses         79       82       +3     
- Partials       23       24       +1     

Impacted Files	Coverage Δ
testcontainers/core/container.py	76.69% <80.00%> (-0.39%)	:arrow_down:
testcontainers/core/policies/_cache.py	92.30% <92.30%> (ø)
testcontainers/core/docker_client.py	53.33% <100.00%> (+2.17%)	:arrow_up:
testcontainers/core/policies/__init__.py	100.00% <100.00%> (ø)
testcontainers/core/policies/always.py	100.00% <100.00%> (ø)
testcontainers/core/policies/base.py	100.00% <100.00%> (ø)
testcontainers/core/policies/default.py	100.00% <100.00%> (ø)
testcontainers/core/policies/maxage.py	100.00% <100.00%> (ø)
testcontainers/mssql.py	100.00% <0.00%> (ø)
testcontainers/mysql.py	84.00% <0.00%> (ø)
... and 6 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

[thedrow]

Looks good, I've left some inline comments.

One larger question is whether we need the additional complexity of the image cache. Directly getting the images from the client takes about 5 ms on my machine. That seems negligible compared with typical runtimes of tests because of the container start-up time. Removing the cache could simplify the code a little. What do you think?

I ported the Java code to work and the cache is present there, which is why it is present here. Note that the same container might be stopped or started multiple times and 5ms for a single query regarding its age might add up to a lot in a very large test suite. If the cache can shave off these calls to Docker, a test suite of significant size should benefit from this cache.

[tillahoffmann]

I have a relatively strong preference to remove the cache for two reasons. First, it's more code to maintain. Second, I don't think the caching will help in most real-world scenarios.

I appreciate that runtime is different across different machines, but getting a single image takes about 4ms on my machine. Using the cache, getting a single image takes about 300ms. It'll of course be quicker the next time images are fetched, but we'd have to use at least 75 containers per test suite to make the cache worthwhile. To have a delay of one second over the cached version, we'd have to run about 325 containers. I'd argue that for a test suite that runs more than 300 docker containers a delay of one second is negligible. But let me know if I misunderstood/miscalculated.