Add boolean validation for tanzu config set feature flags

[mpanchajanya]

What this PR does / why we need it

• Add validation for tanzu config set feature flag value to restrict to boolean true or false values.

Which issue(s) this PR fixes

Fixes #

Describe testing done for PR

• Added unit tests
• Manual testing

> tz config get | grep foo
> tz config set features.global.foo bar
[x] : invalid value provided only boolean true or false are accepted
> tz config set features.global.foo true
> tz config set features.global.foo false
> tz config set features.global.foo bar
[x] : invalid value provided only boolean true or false are accepted
> tz config set features.global.foo ""
[x] : invalid value provided only boolean true or false are accepted
> tz config set features.global.foo true
> tz config get | grep foo
            foo: "true"
> 

Release note

Tanzu CLI will only allow boolean true or false feature flag values

Additional information

Special notes for your reviewer

[marckhouzam]

For completeness let's mention that this PR is technically not a backwards-compatible change. A script could currently run tz config set features.cluster.myfeat TRUE and everything would work but now it will not be able to. Considering the scenarios, I think a small breaking change is ok but I'd like opinions.
@mpanchajanya @vuil @anujc25

If we want to reduce the risk of breakage we could allow the widest, valid and consistent values. Those values must work for both APIs, so they would be true/false, TRUE/FALSE and True/False. That being said, I think true/false is enough but I'd also like opinions.

[marckhouzam]

Just as information:

To properly choose the values we should allow, I thought of checking how the values could be read.
I believe there are two APIs to get a feature flag.

The first API:

config.IsFeatureEnabled("plugin", "flag")

This one uses strings.EqualFold(val, "true") so it accepts case-insensitive true and everything else is false
Ref: https://github.com/vmware-tanzu/tanzu-plugin-runtime/blob/6362240e00b2c0b891141c4d75fe525714e1c755/config/features.go#L40

The other API:

cfg, _ := config.GetClientConfig()
cfg.IsConfigFeatureActivated("features.plugin.flag")

This one uses strconv.ParseBool() which accepts 1, t, T, TRUE, true, True, 0, f, F, FALSE, false, False.
Ref: https://github.com/vmware-tanzu/tanzu-plugin-runtime/blob/6362240e00b2c0b891141c4d75fe525714e1c755/config/types/clientconfig_features.go#L40

This PR can help fix this slight inconsistency by only allowing values that work consistently for both APIs.
What you have coded does that 👍

[anujc25]

For completeness let's mention that this PR is technically not a backwards-compatible change. A script could currently run tz config set features.cluster.myfeat TRUE and everything would work but now it will not be able to. Considering the scenarios, I think a small breaking change is ok but I'd like opinions. @mpanchajanya @vuil @anujc25

If we want to reduce the risk of breakage we could allow the widest, valid and consistent values. Those values must work for both APIs, so they would be true/false, TRUE/FALSE and True/False. That being said, I think true/false is enough but I'd also like opinions.

Thanks for the explanation. Yes, I think this should be fine to accept as the field was used to set a boolean so far.