Merge branch 'develop' to master for 0.1.0 release

Fixed regression with label changes that broke PVC finalizer,

leaving behind PVCs when you removed a stack. Apparently
volumeClaimTemplates completely ignore the labels you give them
and instead use the selector labels for the StatefulSet.

Added apache license and go report card badges

Misc updates to improve go report card

Now running splunk/spark container as same user as splunk

Added liveness and readiness checks to splunk/spark container

Switched splunk image in operator.yaml to default to splunk/splunk:ed…

…ge-redhat

Switched single instances, deployer, cluster master and license master from
using Deployment to using StatefulSet. General best practices suggest that
Deployment should only be used for things that do not need to persist state,
and StatefulSet should be used by everything else.

This also solves the problems with PVC failures in multi-zone clusters.
While PVCs need to be created individually outside of a Deployment, the
PVC templates are embedded within StatefulSets. This allows the scheduler
to ensure that volumes are provisioned according to the rules set for the
Pods rather than independent of those constraints. Most notably, it will
ensure that PVCs for any given pod are all created within the same zone,
for multi-zone clusters.

Merge pull request splunk#20 in TOOLS/splunk-operator from additional…

…-code-cleanup to master

* commit '073f3acca16153c8f1ea64af9c4689da14819e89':
  Added LICENCE file and copyright headers to all source files.

CSPL-36 CSPL-66 This PR includes significant changes to how SplunkEnt…

…erprise CRD Spec's are configured.

The "config" Spec object has been removed, collapsing other parameters up to top-level.

CPU, memory and storage settings are now grouped into a "resources" sub-object.

The "splunkPassword" and "splunkStartArgs" parameters have been removed. The former
has been replaced by a new secrets and configuration management approach. The latter
was dangerous as a configuration parameter since it was both required and changing it
broke things.

Added a new "splunkVolumes" feature that lets you define one or more (read many)
kubernetes volumes, which will be automatically mounted to all Splunk containers.
This can be used to mount shared license files, defaults, apps, or other things and
replaces the previous "splunkLicense" and "defaultsConfigMapName" functionality with
a more general, flexible and easier to understand mechanism.

A "licenseUrl" parameter has been added in place of "splunkLicense" to provide the
location of one or more license files. Either local (absolute path or file:///) or
remote (https:// or http://) references may be used. Note that this is commonly
going to be used in conjuction with "splunkVolumes" to reference license files contained
in ConfigMap objects.

A "defaultsUrl" parameter has been added in place of "defaultsConfigMapName". As per
a corresponding splunk-ansible pull request, this now supports the use of one or more
files. Similar to "licenseUrl", this will commonly be used in conjunction with
"splunkVolumes" to reference license files contained in ConfigMap objects.

A "defaults" parameter has been added that enables additional in-line defaults.yml
overrides to be provided for each SplunkEnterprise CRD. Note that this is a string
field which should contain YAML. When defined, the operator now creates a managed
ConfigMap object for the CRD with the contents in a "default.yml" field, this
ConfigMap is mounted to all Splunk containers, and the defaultsUrl is modified to
append a path pointing to this ConfigMap. Specifying secrets of any kind in configuration
is strongly discouraged, and a new mechanism is described below that makes this easier
to be safe. However, for illustration note that the previous functionality of
"splunkPassword" can be replicated by using:

spec:
  defaults: |
    splunk:
      password: helloworld456

Previously, clustering functionality was broken when a defaults.yml was not explicitly
provided using "defaultsConfigMapName". This was because shared secrets required for
clustering initialization was not consistent across all cluster containers. To fix this,
The operator now always generates random secrets for the following defaults.yml fields:
"splunk.password", "splunk.hec_token", "splunk.idc.secret", and "splunk.shc.secret".
These are put into a new managed kubernetes secret named "splunk-<id>-secrets". In
addition to fields for each of these, it also includes a "default.yml" field that
provides these in a format supported by the default.yml ansible parser. These secrets
are now always mounted to all Splunk containers as "/mnt/splunk-secrets" and the
"defaultUrl" is always prepended with a path pointing to this secrets default.yml.
This allows the operator to always generate working default secrets for the cluster,
which can be overridden using the "defaultsUrl" and/or "defaults" parameters.

Note that if an admin password is not otherwise provided via "defaultsUrl" or
"defaults" configuration, the default admin password generated for the cluster
can be obtained using:

kubectl get secret splunk-<id>-secrets -o jsonpath='{.data.password}' | base64 --decode

Prepended "splunk-" to the "jdk" and "spark" mounts used when DFS is enabled. This
makes it consistent with the other built-in mounts, and helps to avoid name conflicts
with user-provided "SplunkVolumes" mounts.