feat: validate JWT token and use projected token

[cnvergence]

What type of PR is this?

What this PR does / why we need it:

• Validate JWT token against intercepted nodeId and check if the service account name matches irkey stored in the snapshot cache.
• Use the projected service account token and validate against EG audience

Which issue(s) this PR fixes:

Fixes #5863
Followup to the #5137

Release Notes: Yes

[codecov]

Codecov Report

Attention: Patch coverage is 32.29167% with 65 lines in your changes missing coverage. Please review.

Project coverage is 65.81%. Comparing base (9b78828) to head (e792930).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
internal/xds/server/kubejwt/jwtinterceptor.go	0.00%	33 Missing ⚠️
internal/xds/server/kubejwt/tokenreview.go	0.00%	21 Missing ⚠️
internal/xds/cache/snapshotcache.go	0.00%	9 Missing ⚠️
internal/xds/server/runner/runner.go	0.00%	2 Missing ⚠️

❌ Your patch status has failed because the patch coverage (32.29%) is below the target coverage (60.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5871      +/-   ##
==========================================
+ Coverage   65.80%   65.81%   +0.01%     
==========================================
  Files         217      217              
  Lines       36020    36077      +57     
==========================================
+ Hits        23703    23745      +42     
- Misses      10836    10857      +21     
+ Partials     1481     1475       -6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[cnvergence]

I will seperate feature with infrastructure controller namespace into separate PR
xref: #5937

[zhaohuabing]

@cnvergence Talked with @arkodg offline, and he mentioned that we don't need to support gatewaynamespace mode for merged gateway. In that case, the irKey will always follow the "gateway-namespace/gateway-name" format, so we should be able to verify the service account in the jwt claim against the irKey.

Example:

JWT claim: "username": "system:serviceaccount:default:envoy-default-eg-e41e7b31"
IrKey: "default/eg"

We can construct the expected service account using the IrKey, and compare it with the username claim.

@arkodg feel free to add anything if I haven't captured our discussion correctly.

[zhaohuabing]

LGTM.

Discussed with @arkodg , to prevent an envoy from requesting xDS not belong to it, we also need to enforce authz, which can be addressed in a follow-up PR.

Or you can simply revert b0748a0 to add pod check back @cnvergence