Motivation

When building a Docker image in the background, it is sometimes necessary for API parity to also expose the build log to the user.

This PR changes the internal Docker-utils class to return the logs, so that we have the option to expose them where necessary.

Note that the previous method signature was to return None, so this is a non-breaking change.

Testing

The exact build logs are very different between the SDK and CMD.
An example output from the SDK:

Step 1/4 : FROM alpine
---> b0c9d60fc5e3
Step 2/4 : ADD 57334505 .
---> 82c44d1fd396
Step 3/4 : ENV foo=bar
---> Running in 3ff9e2fc6af8
---> Removed intermediate container 3ff9e2fc6af8
---> 527b181ed9b6
Step 4/4 : EXPOSE 45329
---> Running in 3add7fb13f81
---> Removed intermediate container 3add7fb13f81
---> b81d80655ebb
Successfully built b81d80655ebb
Successfully tagged img-69707aab:latest

Building the same image from the CMD:

#0 building with "default" instance using docker driver

#1 [internal] load build definition from Dockerfile
#1 transferring dockerfile: 130B done
#1 DONE 0.0s

#2 [internal] load metadata for docker.io/library/alpine:latest
#2 DONE 0.0s

#3 [internal] load .dockerignore
#3 transferring context: 2B done
#3 DONE 0.0s

#4 [1/2] FROM docker.io/library/alpine:latest
#4 CACHED

#5 [internal] load build context
#5 transferring context: 51B done
#5 DONE 0.0s

#6 [2/2] ADD d95b6ab2 .
#6 DONE 0.0s

#7 exporting to image
#7 exporting layers done
#7 writing image sha256:47ab3fb99ad2840d878e69ce94dcf5430bf6de50dc3c8bab644e91c517f598a1 done
#7 naming to docker.io/library/img-69007ebf done
#7 DONE 0.0s

That's why the test assertions are kept simple. In fairness, I don't think we should make the assertions too strict anyway - what the Docker Engine exactly returns is not relevant, as long as there is some output.