fix(waypoint): treat an empty-valued namespace label as present

[Atishyy27]

What type of PR is this?

/kind bug

What this PR does / why we need it:

namespaceHasLabel (ctl/waypoint/waypoint.go) checked Labels[label] against a non-empty value, so a namespace carrying the label with an empty value (istio.io/use-waypoint set to the empty string, a valid kubernetes label) was reported as not having the label. in kmeshctl waypoint apply --enroll-namespace this makes the !overwrite && hasWaypoint guard fall through and silently overwrite an existing enrollment without the intended warning. this checks for the key's presence instead of a non-empty value. added a regression test.

Which issue(s) this PR fixes:

Fixes #1906

Special notes for your reviewer:

the test uses a minimal fake CLIClient (only Kube() is wired, which is the only method namespaceHasLabel calls) with a fake clientset seeding a namespace labeled use-waypoint="".

Does this PR introduce a user-facing change?:

NONE

[kmesh-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign nlgwcy for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 39.53%. Comparing base (32fe3df) to head (1ba36dd).
⚠️ Report is 3 commits behind head on main.
see 1 file with indirect coverage changes

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ae15e8a...1ba36dd. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[yashisrani]

@Atishyy27 E2E tests are failing .. can you fix it ?

[Atishyy27]

@yashisrani looked into it. the failure is TestMixNsAndServiceWaypoint in the ipv6 lane, and i don't think this PR can reach it.

namespaceHasLabel, the only function this PR changes, has one caller: the --enroll-namespace branch of kmeshctl waypoint apply (ctl/waypoint/waypoint.go:218). the e2e suite never goes through it. TestMixNsAndServiceWaypoint sets the label with a direct API patch in SetWaypoint, and enrollNamespaceOrFail in manage_test.go patches the namespace label directly too, neither one shells out to kmeshctl with that flag. newWaypointProxyOrFail does call kmeshctl waypoint apply but without --enroll-namespace, so it stops short of the changed line.

the same commit passed 2 of the 3 ipv6 runs and every regular e2e run, and the three failing subtests all timed out at exactly 60s waiting on traffic, which reads like the waypoint pod not being ready rather than a label check.

happy to be wrong here. could you retrigger the job? if it fails again on the same test i'll dig further.