https://github.com/kubernetes-helm/community/blob/master/helm-v3/003-state.md#namespacing-changes

TODO reimplement any paging

Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>

Resolves #3655
We were seeing that when running helm upgrade with the reuse-values
flag enabled that you could end up in the position where overrides
a.k.a computed values from previous revisions were not being saved on
the updated revision. This left us in a weird position where some
computed values would disappear mysteriously in the abyss. That
happened because computed values from previous revisions weren't merged
with the new computed values every time the reuse-values flag was used.
This PR merges computed values from the previous revisions so you don't
end up in that kind of conundrum.

Cover hook-succeeded, hook-failed and before-hook-creation hook delete policies.

Existing helm.sh/hook-delete-policy annotation variables (hook-failed, hook-succeeded) do not allow to leave failed jobs for debugging without blocking the next job launching: every failed job must be deleted manually before the next related release is launching (installing, updating or rolling back).

New policy, before-hook-creation, removes the hook from previous release if there is one before the new hook is launched and can be used with another variable.

Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>

When using `helm upgrade --install`, if the first release fails, Helm will respond with an error saying that it cannot upgrade from an unknown state.

With this feature, `helm upgrade --install --force` automates the same process as `helm delete && helm install --replace`. It will mark the previous release as DELETED, delete any existing resources inside Kubernetes, then replace it as if it was a fresh install. It will then mark the FAILED release as SUPERSEDED.

* add test for rolling back from a FAILED deployment

* Update naming of release variables

Use same naming as the rest of the file.

* Update rollback test

- Add logging
- Verify other release names not changed

* fix(tiller): Supersede multiple deployments

There are cases when multiple revisions of a release has been
marked with DEPLOYED status. This makes sure any previous deployment
will be set to SUPERSEDED when doing rollbacks.

Closes #2941 #3513 #3275

Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>

Set it to match the server side, or the default limit
of 4MB will still apply when upgrading charts.

Fixes #3512

Between grpc 1.2.x and 1.7.x there was an API change. The
previous MaxMsgSize is now a wrapper around MaxRecvMsgSize. This
change now sets the MaxRecvMsgSize and MaxSendMsgSize which need
to be set independently.

Add an optional field kubeVersion to Chart.yaml that allows the chart
developer to specify a semver compliant version.

Closes #2708, #2706