Full Status tab improvements for VTAdmin

[GuptaManan100]

Description

The PR #11438 introduced the Full Status tab in the vttablets in VTAdmin which shows the full replication status of the tablets.
In this output it was noticed that the IO state and SQL state are printed as integers (because they are stored as an enum), instead of any meaningful output, so it becomes hard for the users to read this data unless they are familiar with Vitess internals on how the enum works.

This PR attempts to improve this situation by decoding these values before printing them using a replacer function in the json.Stringify.

Another thing that was noticed was that the semi-sync properties weren't printed if they are false. This is not desirable. We instead always want to print these settings. This PR addresses this too. It checks for these fields being explicitly set to true. If they aren't, then we set them to false.

Here are the images of the Full Status tab after the changes -

Related Issue(s)

Checklist

• "Backport me!" label has been added if this change should be backported
• 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 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.

[ajm188]

LGTM, but a question about the presentation :)

[notfelineit]

I left a few suggestions for cleaning up the code 😄 Potentially the swaps from integer --> human readable state could be done at the API level in the future - since there could be multiple clients for this API.

[deepthi]

I left a few suggestions for cleaning up the code 😄 Potentially the swaps from integer --> human readable state could be done at the API level in the future - since there could be multiple clients for this API.

This would be preferable so that we don't have to keep two places in sync. However, I suspect that because we are returning a protobuf from the RPC, we don't have much of a choice.
Unless we change the protobuf itself to contain strings instead of enum values.

[GuptaManan100]

@notfelineit Thank-you for all the suggestions! I have fixed them all up. @deepthi is right about the reason why I implemented the changes in the typescript side instead of the API. In the typescript code, we also verify that we indeed get the result matching the fields of the proto message and their types.
The alternate way to do to in the API would entail creating a different type called FullStatusReadable which has the enum changed to strings and omitempty removed from some of the fields that we always want printed. Then the API would return this type instead of FullStatus. However, we would still have the same drawback that we have now, which is to keep the two in sync. Right now it is the enum and string values we print in the UI, the alternate would be the two proto message types.

[GuptaManan100]

This is how the UI looks after the review comments -

[vitess-bot]

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

[notfelineit]

@deepthi @GuptaManan100 that makes sense regarding the API proto! This looks good!