Bootstrapping docker container for sample datasets

[krishnangovindraj]

What is the goal of this PR?

Introduces a docker image which downloads a config file from GitHub and loads the datasets into a typedb version specified in the config.

What are the changes implemented in this PR?

Adds

• A Dockerfile for the image which contains:

• boostrapper.py: Python script which sets up the
• The gpg key for the cloudsmith apt repo, preloaded.

• A config file for the bootstrapped at the expected location (this location is hard-coded in the bootstrapper)
• A factory test which builds an image, containing the config file and datasets files and runs it + tests it is available.

Reasons for 'do not merge'

• CI will fail currently, Since the datasets in config.yml are only on jameswhiteside/development. We can edit this out / Add a sample instead.
• Once we're happy, we need to push version 1.0.0 of the docker image to dockerhub.

# From the root of the repo
> docker login # As someone who has rights to push
# Comment out the lines to copy the datasets in. That's only needed for CI.
> docker build  . -f typedb-samples-docker/Dockerfile  --tag vaticle/typedb-sample-datasets:1.0.0
> docker push vaticle/typedb-sample-datasets:1.0.0 

We should not need to release a new version unless the bootstrapping process (or something hardcoded in it) changes.

[typedb-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• This change is trivial and does not require a code or architecture review.

Code

• Packages, classes, and methods have a single domain of responsibility.
• Packages, classes, and methods are grouped into cohesive and consistent domain model.
• The code is canonical and the minimum required to achieve the goal.
• Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• The code is algorithmically efficient and scalable for the whole application.

Architecture

• Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• Any required build and release automations are updated and/or implemented.
• Any new components follows a consistent style with respect to the pre-existing codebase.
• The architecture intuitively reflects the application domain, and is easy to understand.
• The architecture has a well-defined hierarchy of encapsulated components.
• The architecture is extensible and scalable.

[krishnangovindraj]

self review

[krishnangovindraj]

How often would we want to run this test?
It shouldn't be significantly longer than testing it against a local installation of TypeDB, which is the alternative.

The test has run successfully in CI: https://factory.vaticle.com/krishnangovindraj/typedb-docs/1168c68815d9f9fa01580dbc4f8a9233607d677a/build/1/correctness/1/test-sample-bootstrapper/1

[krishnangovindraj]

A bootstrapper-version for if/when we have to make breaking changes.

[krishnangovindraj]

The lack of exec on the first also means we can't interrupt the container bootstrap

[krishnangovindraj]

Overrides for testing with local files. This can be used to test against a local typedb instance, or in a locally built docker container as the CI test does.