Add cache for jdbc metadata calls

[NikhilCollooru]

Created custom build with changes and tested by shadowing prod queries.

== RELEASE NOTES ==
Jdbc Changes
* Add cache support for jdbc metadata calls. This can be enabled by configuring parameter `metadata-cache-ttl`, `metadata-cache-refresh-interval` and `metadata-cache-size`.

[jainxrohit]

Can you share some results what improvements did you see?

[NikhilCollooru]

Can you share some results what improvements did you see?

[NikhilCollooru]

The cache metrics can be seen like this

[jainxrohit]

The cache metrics can be seen like this

We need to add all these new metrics to admin dashboards.

[jainxrohit]

LGTM

[rschlussel]

I think it would make sense to switch the control flow, so have CachingJdbcMetadata have JdbcMetadata as a delegate and implement all the methods that JdbcMetadata does, and call to the delegate for everything (sometimes a simple call, sometimes as part of loading into the cache).

a) this is how i think all of our other CachingXXX classes work
b) it means all of the actual implementation for getting the metadata is in one place, and the only thing that needs to know about what the cache supports is the CachingJdbcMetadata. The JdbcMetadata doesn't need to know which things it can get from the caching metadata (which only implements some things from the interface, but the whole connectormetada interface is available and has default implementaiton) and which things it needs to get itself

[NikhilCollooru]

I think it would make sense to switch the control flow, so have CachingJdbcMetadata have JdbcMetadata as a delegate and implement all the methods that JdbcMetadata does, and call to the delegate for everything (sometimes a simple call, sometimes as part of loading into the cache).

a) this is how i think all of our other CachingXXX classes work b) it means all of the actual implementation for getting the metadata is in one place, and the only thing that needs to know about what the cache supports is the CachingJdbcMetadata. The JdbcMetadata doesn't need to know which things it can get from the caching metadata (which only implements some things from the interface, but the whole connectormetada interface is available and has default implementaiton) and which things it needs to get itself

The issue is that we need CachingJdbcMetadata to be singleton so that the cache inside it will be shared across queries. But JdbcMetadata is not singleton and an instance is created for every trasaction/query. So switching the flow will not work.

After offline discussion, we decided we will keep the flow same, but will CachingJdbcMetadata(renamed to JdbcMetadataCache) will just be a cache and NOT implement ConnectorMetadata.