Draft: Images: add image context builder script and remove usage of symlinks

What

Remove usage of symlinks in images/.

Why

Some images, like images/client-libs-dependencies use symlinks to put commonly used code in their build context directory. Currently, the build context of an image FOO is created from the build context directory images/FOO. To build the image, we tar the build context directory to create the build context, which is piped to docker build. Tar resolves any symlinks in the build context directory. This allows us to include files from outside the build context directory in the build context. This is used for e.g. images/client-libs-dependencies/package.json that links to ./package.json in the root.

However, symlinks have posed issues in the past, since they do not work well in Windows.

How

Instead of using symlinks, each build context directory now includes an optional file includes. It specifies a set of files that should be included in the images build context in addition to any files in inputs. Like inputs, any includes are hashed to produce the input hash.

A new script scripts/image_context.sh is added which creates a temporary directory and writes the build context of an image there in, by copying the build context directory followed by all paths mentioned in includes. If there is a name clash between a file in the build context directory and an include, then the script fails.

Manually testing the MR

Test image_context.sh:

$ VERBOSE=yes ./scripts/image_context.sh images/client-libs-dependencies
# you can remove the temporary directory that was created

Test its usage when creating the client libs dependencies image.

$ ./scripts/create_client_libs_dependencies_image.sh

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR