Examples: Add lib functions to wait for shard states

[mattlord]

Description

Before modifying a shard we need to wait for the tablets to be up, a primary to be elected, and that primary to become healthy/serving. We were skipping this last check, but in practice it was virtually never an issue because the transition to primary after election (by vtorc now) was so fast. After #11520, however, once the primary has been elected it then needs to initialize its sidecar database. This additional time, while small, now makes the local examples unreliable because we do not wait for that to happen before we e.g. execute the ApplySchema vtctl client command. We also did not check for any errors in vtctl client commands like that, so you would not know anything was wrong until trying to execute a later step or command and you would see that e.g. the tables did not exist. In the process, I also made the following notable changes:

Note I took this opportunity to remove an annoying and unnecessary step in the region_sharding examples of having to specify a full path to countries.json — which meant that the examples did not work w/o taking that manual step — when a relative path works and we're using relative paths everywhere else in the examples.

Note I realized that there was a lot of duplicated files/code between the local and region_examples, so I took the opportunity to refactor these so that they share the same files between them (this will require a docs PR now too).

Related Issue(s)

• Related to: vttablet sidecar schema:use schemadiff to reach desired schema on tablet init replacing the withDDL-based approach #11520

Checklist

• "Backport to:" labels have been added if this change should be back-ported
• Tests are not required
• Documentation: Documentation updates from #12239 website#1380

[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.

[GuptaManan100]

looks good to me apart from the outstanding comments.

[rohit-nayak-ps]

Great changes, thanks!

[frouioui]

This is looking good to me! Thank you for doing this @mattlord, this is awesome work 🙌🏻

[vitess-bot]

I was unable to backport this Pull Request to the following branches: release-16.0.