Javadoc was quite confusing as the build is actually a FAILURE if tearDown returns false and not ABORTED

Conflicts:
	changelog.html

If the user still has the API token that's generated from secret.key,
don't accept that.

Hopefully this is the last fix

If JENKINS_HOME is created by a post SECURIT-49 Jenkins (LTS, and other
variants), then there's no need to alarm the user.

I look at javadoc only from IDE as a part the source code, I just won't notice package-info.java.

This is because we discovered some plugins that use Secret early on in
the initialization.

As an AdministrativeMonitor, it shows up in the manage Jenkins UI, and
allows the administrator to run a re-keying operation.

We are replacing it by the ConfidentialStore class and the
ConfidentialKey class, which provides purpose-specific confidential
information that are separated from each other.

In this way, not all eggs are in one basket, and in case of a
compromise, the impact will contained.

Also replaced several insecure use of digest(secret|messsage) or
digest(message|secret) by HMAC.

[FIXED JENKINS-13655] Enable transparent log decompression support (Jenkins v1.485)