Keep tarball and release properties for release

The installer file created by the package role can not be scanned by
JFrog XRAY due to it being an incompatible artifact type. In order for
the artifact to be scanned, it needs to be in one of the supported
formats.

This change updates package role to keep the tarball if the packaging
is run by release job in order to make scanning of artifacts possible.

In addition to keeping the tarball around, release job records release
metadata in release.properties file. This file is needed to be included
in tarball and installer file in order to make the traceability better.

Please note that both of these operations take effect if the release
metadata file /tmp/release.properties exists. This file is only created
by release job on Jenkins and does not exist for manual builds so there
is not change for manual packaging.

Change-Id: I64a4d96207a1b8862440128ade87f93f03269e63

Introduce stack setup script

This change introduces setup-stack.sh script which will do setup
for the stack itself such as setting the default scenario if not
specified by the user and more importantly installing the dependencies.

Further changes will be sent, moving dependencies to stacks and
installations of those into stack setup script.

Depends-On: I6b9d27edd2016594b197a368b8ed393e98beef7f
Change-Id: I7892fa217a7db5c0c7b84a1b57aa6f311ee14cc6
(cherry picked from commit d7c1e7673b19be3c8ee33283762aba19a606b6cd)

Control docker version within stack

Docker version was originally controlled within engine repository
but it is more appropriate to control it within the stack as the
version requirements could be different across the stacks. See the
dependent change for how it was controlled before.

Depends-On: Id5f2c72e35bba4d5ab413f7b19119330540f5674
Change-Id: I2720d6b6ddcde0f742f527e3f86b3085f13aaeda
(cherry picked from commit bfdd3d8ef9d2aa002bab69ebd36f971df3918146)

Bring Kubernetes 1.15

This change brings K8s 1.15 to Nordix. Some notes about
K8s 1.15 support of engine.
- The support is only included for the scenario k8-calico-nofeature.
- Deployment with the scenario k8-multus-plugins fails and
other scenarios are not tested since they may not be relevant
for us anymore. Due to this those scenarios have been removed from
1.15 branch.
- Installer, infra/installer/kubespray, 1.15 branch is tracked by
this branch.

An example command to deploy K8s 1.15 in online mode with the engine is.

- clone engine repo as usual
- cd engine/engine
- ./deploy.sh -s kubernetes -b 1.15 -c k8-calico-nofeature \
    -p <path to pdf> -i <path to idf> -v

If you are deploying on OpenStack using Heat, you need to
- specify the location of openrc file
- pass heat environment file as pdf

An example command to package K8s 1.15 for offline deployment with the
engine is.

- clone engine repo as usual
- cd engine/engine
- ./package.sh -s kubernetes -b 1.15 -v

Change-Id: Ic594b74780b6cdc309e36c24cea75e8e60863b2b

Move pre, postinstall, scenario, and apps to stack

Preinstall, postinstall, scenario, and apps are specific
to stack composition and more appropriate to locate them
within the stacks themselves rather than the installers.
This makes it possible for different stacks to configure
target deployment according to their needs and use the
installer without thinking about potential effects the
changes could cause on other stacks that may be using the
same installer.

An example to this is Kubernetes and ONAP stacks and the
CEPH configuration. Both stacks use Kubespray but the
configuration of Kubernetes differs between them. By moving
the pre/post/scenario/app configuration into stacks
themselves, they become independent from each other as
much as possible.

Please note that once this change goes in, the dependent
change needs to be verified and submitted in order to
conclude the transition.

https://gerrit.nordix.org/c/infra/installer/kubespray/+/5157

Change-Id: I24d7e9546034b385565708f528ed9caddf03ae26

Create engine kubernetes stack

This change creates kubernetes stack for engine in order to package,
deploy, and test stacks independently from engine core.

The main feature this enables is the ability to develop stacks
in their own repository with proper versioning and branching no
matter how the tools (provisioner and installer) are developed.
The stack simply selects versions of the tools (could be branches)
and the rest is done accordingly.

The role package which was previously located under
infra/installer/kubespray is moved into this repository in order to
handle what to package within the stack since some of the artifacts
we package do not belong to installer but to the stack itself.

Change-Id: I760d4d904544dad768525e999ebe53e156464111

Set up repository

Change-Id: Ia4bc2dd99a5ec808af1be471ce32ad8a1021b68c

Initial empty repository