App does not load with a proxied DataSource using Hikari

[evernat]

With Spring-boot 2.0.0.RC2, when using HikariCP and a datasource proxy or any wrapper around a datasource, there is UnsatisfiedDependencyException:

Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'org.springframework.boot.autoconfigure.jdbc.DataSourceJmxConfiguration$Hikari': Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.factory.BeanNotOfRequiredTypeException: Bean named 'dataSource' is expected to be of type 'com.zaxxer.hikari.HikariDataSource' but was actually of type 'com.sun.proxy.$Proxy49'

Instead of a blocking exception I expect this to succeed like it was in Spring-boot 1.x.

Test case:
https://github.com/evernat/datasource-proxy-hikaricp
Use mvn spring-boot:run and see UnsatisfiedDependencyException instead of success.

The test case uses a DataSourceBeanPostProcessor to create a proxy as just a "a wrapper around the original" as suggested by the BeanPostProcessor's javadoc and it does not use ProxyFactory.setProxyTargetClass(true) to create a CGLIB proxy.

I think that it should still work in Spring-boot 2.0 and there are several really valid use cases for setProxyTargetClass(true) not being used in my opinion:

1. Calling setProxyTargetClass in this case is not needed in Spring-boot 1.x. And JMX enabled by default is not a good reason to change that in Spring-boot 2.x.
2. Or the datasource proxy may not be created by the application's code and may not be created with Spring either.
3. Or CGLIB may not be available in this application.
4. And the BeanPostProcessor's javadoc only suggest to create here a "wrapper around the original" as a standard practice ; it does not suggest to create a CGLIB proxy.

so why Spring-boot 2.0.0.RC2 requires to use CGLIB here to create a proxy of a standard DataSource ?
(The fact that it is a HikariDataSource and that Spring-boot registers the HikariDataSource into JMX is unknown in the DataSourceBeanPostProcessor by separation of concerns and should also be transparent for the application as much as possible in my opinion.)

I will submit a PR in a minute.

[evernat]

For the PR, I think that Spring-boot should do the best it can do to find the needed HikariDataSource.
By the best it can do, I mean:

1. Test if dataSource instanceof HikariDataSource (like today)
2. Else test if dataSource.isWrapperFor(HikariDataSource.class) and if yes, use dataSource.unwrap(HikariDataSource.class)
3. Else throw an exception (like today)

PR #12272 is created as such.