VTOrc Code Cleanup - generate_base, replace cluster_name with keyspace and shard.

[GuptaManan100]

Description

This PR does more cleanup for the VTOrc codebase.

1. The first cleanup is to merge the generateBase and generatePatches SQL commands into a single one. The create table statements and alter tables have coalesced into one. This refactor has been achieved by running VTOrc and then taking the schema dump of the SQLite database. After that DROP TABLE commands are added corresponding to all CREATE TABLE commands. This ensures that every time VTOrc starts it cleans up the previous tables and data if they exist, and then creates new tables with the new schema. Since VTOrc's data is ephemeral, this is okay.

2. Cleanup the usage of IsSQLite and IsMySQL given that VTOrc only supports SQLite3 as the backing store. These functions earlier returned true and false respectively.

3. Remove unused code.

4. Remove unused table cluster_domain_name, host_attributes. These tables were only inserted into and not read from. Moreover, the information stored in these tables is no longer needed. Earlier in orchestrator, the cluster was named by the primary's address, but now it is the keyspace shard name. This value doesn't change and doesn't need domain name information.

5. Change storage of cluster_name to instead store the keyspace and shard. This is a much required cleanup pending for a while. Instead of storing cluster_name as a single value in the database, instead keyspace and shard should be stored separately. Moreover, this information shouldn't be stored in the database_instance table at all, since it is available in the vitess_tablet table.

6. Remove InjectUnseenPrimary. This is not required in VTOrc. VTOrc discovers tablets registered in the topo server. If there is a tablet replicating from an instance which isn't in that list, then we should be fixing that replication instead of trying to discover that unseen primary.

7. Remove InjectSeed when we open tablet discovery. It didn't run anyways since the leader election doesn't happen until the first health tick runs. So this code exits and doesn't do anything. Moreover discovery of tablets doesn't need InjectSeed code, we should use the DiscoverInstance for this.

Replacing cluster_name with keyspace and shard gives us an additional benefit, which is of filtering in some of the APIs can now support filtering just by the keyspace. Tests for these APIs have been added.

Related Issue(s)

• RFC: Orchestrator as a native Vitess component #6612

Checklist

• "Backport to:" labels have been added if this change should be back-ported
• Tests were added or are not required
• Documentation was added or is not required

Deployment Notes

[vitess-bot]

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

• Ensure that the Pull Request has a descriptive title.
• If this is a change that users need to know about, please apply the release notes (needs details) label so that merging is blocked unless the summary release notes document is included.
• If a test is added or modified, there should be a documentation on top of the test to explain what the expected behavior is what the test does.

If a new flag is being introduced:

• Is it really necessary to add this flag?
• Flag names should be clear and intuitive (as far as possible)
• Help text should be descriptive.
• Flag names should use dashes (-) as word separators rather than underscores (_).

If a workflow is added or modified:

• Each item in Jobs should be named in order to mark it as required.
• If the workflow should be required, the maintainer team should be notified.

Bug fixes

• There should be at least one unit or end-to-end test.
• The Pull Request description should include a link to an issue that describes the bug.

Non-trivial changes

• There should be some code comments as to why things are implemented the way they are.

New/Existing features

• Should be documented, either by modifying the existing documentation or creating new documentation.
• New features should have a link to a feature request issue or an RFC that documents the use cases, corner cases and test cases.

Backward compatibility

• Protobuf changes should be wire-compatible.
• Changes to _vt tables and RPCs need to be backward compatible.
• vtctl command output order should be stable and awk-able.
• RPC changes should be compatible with vitess-operator
• If a flag is removed, then it should also be removed from VTop, if used there.

[rsajwani]

Does this PR entail any changes on VTGR?

[GuptaManan100]

I really did not like the architecture where VTGr was using the same code as VTOrc. This was preventing a bunch of refactors by tying both the two components together. Given that they are inherently operating in different architectures, (semi_sync vs group replication), it didn't make sense to me for them to have the same configurations or the same schema for their database. So in an earlier refactor, #11356 I had severed these ties between the two and copied all the code that vtgr was also using into its own directory. Now there is nothing that vtgr uses from the vtorc directory. The changes to the VTOrc schema don't concern vtgr anymore. It has its own generate_base and generate_patch file which are unchanged.

[deepthi]

Nice work. If you think it is worth blocking API calls that provide shard but no keyspace, can you go ahead and implement that?
Rest LGTM.

[GuptaManan100]

@deepthi 👍 I have added code to prevent filtering just by the shard and added end to end testing for it.