Switch from deprecated HttpClient API and allow Client Certs for Jenkins

[pdodds]

We have hit a requirement to secure the Jenkins instance behind client certificates.

For this rather than getting the key material provided by the form it is probably easier to allow that a keystore is provided from the environment in which Stash is running.

This allows the Stash admin to provide a key in a Java keystore and then present that key when we connect to the Jenkins instance.

If you are up for it I'm happy to add more documentation on the approach to the readme

[anandsterlite]

I love the approach, it adds credibility to the plugin.

[mikesir87]

I'm sorry I didn't get back to comment on this pull request. My only hesitation in merging this right now is that only 10% of the Stash instances using the plugin are using the 3.10.x version that's being referenced in your updated POM. As much as I'd like to use this, I don't want to leave everyone else behind.

I don't recall at what point the Stash codebase was updated to allow our own version of HttpClient to be used, but I know that was an issue for a while. Do you have any ideas on that?

[pdodds]

The Stash codebase was updated in 3.9.2 to support the new HttpClient

https://jira.atlassian.com/browse/STASH-2970

I know it is a tricky once since we needed to support these requirements for PCI compliance within our build infrastructure.

[matthewbarr]

Should there be any updates to the documentation to go along with it?

[pdodds]

I have updated the plugin to use the stash-config.properties rather than environment variables and also updated the README

[mikesir87]

Sorry for the long delay here. How about this approach? With the upcoming Stash 4.0 release, it gives me a good chance to basically rework the codebase and have a cutpoint. With Stash 4.0, I'd like to release version 3.0 of this plugin, where I definitely want this to be included.

Are you ok with holding out that long?