PHOENIX-5544: Dropping a base table with cascade with an older client does not clear all child view metadata

[ChinmaySKulkarni]

Please review @twdsilva @lhofhansl

This PR makes the following changes:

1. Added ViewUtil#getSystemTableForChildLinks which provides us whether we should use SYSCAT or SYS.CHILD_LINK to process parent->child links.

2. First connection is from a 4.14 client:

   • When creating/dropping a view, continue using SYSCAT for parent->child links since the SYS.CHILD_LINK table does not exist yet.
   • Disallow dropping a base table that has child views.

3. First connection is from a 4.15 client (so we have upgraded the metadata) and a subsequent connection is made from a 4.14 client:

   • During view creation, the old client will send all the parent->child link mutations to SYSCAT since the client-side change for ChildLinkMetaDataEndpoint (PHOENIX-4810) is not present. In this case, we continue sending server-server RPC from the SYSCAT region to the SYSTEM.CHILD_LINK region and store parent->child links in the CHILD_LINK table rather than SYSCAT.
   • When dropping a base table with child views with the cascade option, we add a DropChildViewsTask just like any 4.15 client would.
   • Also just like the 4.15 client, if we recreate the base table before its DropChildViewsTask is completed, we explicitly drop the child views for that table.

No change for connections from 4.15 clients throughout.

Tested the repro I mentioned in the JIRA with a 4.15 server (tested with NS-mapping enabled and disabled):

1. First 4.14 client: Create table, create view, drop table cascade -> fail , drop view pass, drop table pass
2. Then connect a 4.15 client: Same ddl as above, all passed.
3. Then reconnect the 4.14 client: Repeat same DDL, all passed including drop table cascade.

[twdsilva]

LGTM, thanks for fixing this.

[ChinmaySKulkarni]

Thanks for the review @twdsilva. Precommit is broken as usual. I ran seemingly relevant tests locally and they all passed. I will commit this.