Allow a custom ExecutorService to be set for each pool

[keir-nellyer]

This allows for HikariCP to be used when a SecurityManager is in place, preventing/warning of the creation of threads not using the applications main ExecutorService. One such application is BungeeCord, you can see it's security manager here. Currently it's only warning of the action.

I believe Android also has a similar limitation in place.

Users of the library may also want to change the ExecutorService so that they can reuse it throughout their project.

[brettwooldridge]

What about the housekeeping timer thread? Wouldn't that issue a similar warning?

[brettwooldridge]

It also appears that BungeeCord will not issue a warning if the Threads are created through the GroupedThreadFactory: BungeeSecurityManager:58

Using an external Executor could be bad news for the pool, causing lock-ups etc. because we are at the whim of whoever configures the Executor. For example an Executor with a CallerRunsPolicy.

In lieu of specifying an Executor, I would prefer to allow the specification of the ThreadFactory that is used by the Executor that HikariCP instantiates.

[keir-nellyer]

@brettwooldridge Okay, that was definitely something I overlooked and appears to be a much better solution, implementing and testing now.

[keir-nellyer]

I've implemented specifying a custom thread factory, however I don't think there's any way to control how the Timer class creates it's thread without creating our own (we can't even extend it to sort the issue).

A way around this would be to switch over to using a ScheduledThreadPoolExecutor in place of the timer and just have a poolSize of 1 (or more, although I think 1 is enough as that is what a Timer effectively was). I want to make sure though that the ScheduledThreadPoolExecutor won't add any extra overhead having the pooling features.

[keir-nellyer]

Okay, I've figured a way round the issue with Timers and now using a ScheduledThreadPoolExecutor too, I did change some method parameters in one of the interfaces, I'm not sure if any applications using HikariCP will be using that interface. When I commit it I'll show you what I mean.

If it does break anything I can probably add a deprecated method that will prevent any applications breaking due to the change.

[keir-nellyer]

Darn, will try get rid of that merge commit. Nevermind, fixed. GitHub makes me look crazy by removing the commit messages that were there.

[keir-nellyer]

Updated to changes suggested.

[keir-nellyer]

The Travis build failed due to not being able to connect to the database, doesn't seem like an issue with this PR.

[brettwooldridge]

Thanks for the contribution!

[keir-nellyer]

Thanks for merging!