Added a constructor for HikariConfig that accepts a Properties object. M...

[swaldman]

...odified props-file reading constructor to use try-with-resources to ensure prompt file close.

The motivation here is integration with app servers and other projects that might wish to integrate HikariCP and allow configuration from their native config files. Such projects could read properties one by one and call set methods directly on the HikariConfig object, but that's fragile: if HikariCP ever adds new config, these projects will have to be updated to support them. With a constructor that accepts a Properties object, other projects can read their own native config, extract HikariCP-related properties based on a section or prefix, and construct their DataSource from whatever is found without worrying about HikariCP-specific config details.

(Also, the Properties-file based constructor opens but does not close a file descriptor; since HikariCP is a Java7+ project, try-with-resources is a quick way to ensure reliable resource cleanup.)

[swaldman]

done, re pull request to dev.

i'm don't think setDataSourceProperties( ... ) does what i want. browsing the code, it looks like these properties get bound to a nested DataSource from which Connections are acquired to be pooled. i want to be able to set HikariCP configuration properties from config that might look like...

HikariCP {
    acquireIncrement=3
    acquireRetryDelay=1000
    connectionTestQuery=SELECT 1
    dataSourceClassName=org.postgresql.ds.PGSimpleDataSource
    dataSource {
          username=test
          password=test
          databaseName=mydb
          serverName=localhost
    }
}

i want to be able to convert from that format to a HikariConfig without having to individually set parameters or reproduce the work your bean setter does to parse nested DataSource properties. all i have to do is find the HikariCP prefixed paths, flatten nested keys to period-separated paths, and hand them off as a property to the method you've already defined for converting props to config. i certainly could do that just by using PropertyBeanSetter.setTargetFromProperties( ... ) directly, but that seems hackish and perhaps fragile as HikariConfig evolves. you've already committed to supporting a mapping between Properties and HikariConfig in your public api, so there should be little extra maintenance burden in supporting that both from files and from Properties objects.