US1094711:- Add httpMethods field to L7Api PortalMeta for per-API HTTP method restriction

[ksaladi]

What

Adds an httpMethods field to PortalMeta on the L7Api CRD so Portal API authors can
restrict which HTTP verbs a published API accepts (e.g. GET only), instead of the Gateway
unconditionally allowing all 7 verbs.

Changes

• api/v1alpha1/l7api_types.go: new HttpMethod enum type (8 consts) + HttpMethods []HttpMethod
  on PortalMeta.
• internal/templategen/templategen.go: mirrored HttpMethods []string on PortalAPI (required
  for the PortalMeta → PortalAPI JSON round-trip in deployL7ApiToGateway).
• internal/templategen/portal-api-restman-template.qtpl (+ regenerated .qtpl.go): <l7:Verbs>
  now emits from HttpMethods when set, falling back to the existing hardcoded 7-verb list when
  unset — fully backward compatible.
• CRD schema regenerated in all 3 locations (config/crd/bases/, bundle/manifests/,
  charts/layer7-operator/crds/).
• Added a test case covering the restricted-methods path in templategen_test.go.

Enforcement itself is native to the Gateway via Graphman's WebApiServiceInput.MethodsAllowed —
no new assertion logic.

Testing

• go build, go vet, go test ./internal/templategen/... — all pass.
• Verified live on a kind cluster: patched an L7Api CR with httpMethods: ["GET"], confirmed
  via the Gateway's Graphman API that methodsAllowed matched, and confirmed POST/DELETE
  are rejected with "HTTP method ... not allowed" while GET passes through to policy.

[jb683638]

[Nit] ❌ gofmt reports this block as misformatted: running gofmt -l internal/templategen/templategen.go on this branch flags this file. The struct-tag column padding on PublishedTs/CreateTs/ModifyTs/SsgServiceType doesn't match what gofmt would produce after adding the HttpMethods field.

✅ Run gofmt -w internal/templategen/templategen.go (or make lint-fix) before merge so CI's fmt check doesn't drift.

[ksaladi]

Fixed — ran gofmt -w.

[jb683638]

LGTM

[jb683638]

[Suggestion]

❌ Issue: This test only exercises the new restricted-methods branch. The modified conditional in the qtpl template (if len(portalApi.HttpMethods) > 0 { ... } elseif isSoapApi == "true" { 2 verbs } else { 7 verbs }) also touches the pre-existing default and SOAP branches, but there's no test asserting those still produce the original verb counts now that HttpMethods is unset/empty for them (the existing "Template Test" above only checks the output is non-empty).

✅ Suggestion: Add an assertion (e.g. strings.Count(got, "<l7:Verb>") == 7 for the default portalApi case, and a SOAP-API case with isSoapApi == "true" expecting 2) so a future change to this shared conditional can't silently regress the backward-compatible default path this PR's description calls out as important.