[YugabyteDB plugin] Use single connection for both schema history table management and applying migrations

[ashetkar]

What

• Fix for GH Issue Flyway migrations with ALTER TABLE ... RENAME COLUMN may fail with YBDB 2.20+ yugabyte/yugabyte-db#23327
  • Currently, the plugin uses a separate connection to manage schema history table and migrations are applied in another thread.
  • This was causing catalog version mismatch issues when one thread altered catalog version while another was querying a pg_catalog.pg_class table inside a transaction.
  • The fix is to use single connection for both schema history table management and applying migrations
• Also, made the tableEntries map a static variable in YugabyteDBExecutionTemplate
  • This map keeps track of which entries are added to the lock table across different migrations from within the same app. Earlier, being an instance variable it was getting reinitialised for each migration and not serving its purpose.

Testing

Ran modified tests from flyway-tests repository. PR available yugabyte/flyway-tests#3.

[ashetkar]

cc @Barry-RG Please take look. Thanks

[ashetkar]

Gentle reminder. Thanks!