fix performance for UPDATE_TS_EXTENTS

[Enovotny]

currently in CWBI UPDATE_TS_EXTENTS is taking 20 hours to run. take recommendation from Dave Portin to improve the performance.

related to

https://jira.hecdev.net/browse/CWDB-260

biggest issue appears to version dates. how to obtain version dates. recommendation is to us TS_EXTENTS table itself, but in CWBI that information is not copied in goldengate. Is there a possibility to copy that information and not the actual extents since the extents can be different in cwbi from T7. other methods for how to determine version dates?

separate the job to only calculate the date extents? have min, max values etc. calculated in a different job that runs less frequently.

Frist part of this ticket would be to review the work Dave did then come with some recommendation for improvements.

other tickets that might be related

https://jira.hecdev.net/browse/CWDB-264
https://jira.hecdev.net/browse/CWDB-282

[adamkorynta]

Called out in CWDB-282 was Dave's recommendation TSV Tables Primary Key - should we consider (test?) other PKs? Perhaps move version_date before date_time TS_CODE, VERSION_DATE, DATE_TIME? This probably requires some testing. I think that my early testing showed it was a tradeoff. .

I believe still the most prominent use-case is to retrieve the max version-date for all time steps for a given time series (as opposed to always providing a specific version date). Therefore, I don't think we should reorder the columns in the primary key. @HydrologicEngineeringCenter/cwms-database-devs any thoughts?