ESD-1615: add matrix-aware NAT gateway speed/session validation

[Phil-Browne]

NAT gateway create only checked that speed and session count were positive, so an unsupported speed/session combination reached the API instead of failing pre-flight. This bumps megaportgo to v1.15.0 and uses its NATGatewaySpeedSessionSupported helper to check the pair against the live availability matrix before ordering, listing the valid speeds and session counts if it's rejected.

• Fetch the matrix via ListNATGatewaySessions and validate the requested speed/session pair against it in nat-gateway create
• Fail open on a matrix fetch failure or empty matrix (the API still enforces the rule at order time), matching the Terraform provider's handling
• Add stub mock methods for the new MCR ping/traceroute interface methods that came in with the same SDK bump, so mcr keeps compiling (the commands themselves are ESD-1614)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.53%. Comparing base (85c4a85) to head (0eba9d5).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #507   +/-   ##
=======================================
  Coverage   78.52%   78.53%           
=======================================
  Files         192      192           
  Lines       18474    18493   +19     
=======================================
+ Hits        14507    14523   +16     
- Misses       2902     2904    +2     
- Partials     1065     1066    +1     

Files with missing lines	Coverage Δ
...ternal/commands/nat_gateway/nat_gateway_actions.go	81.79% <100.00%> (+0.96%)	⬆️

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Pull request overview

Adds pre-flight validation for NAT Gateway create so unsupported speed/session-count combinations are rejected client-side (using the SDK’s matrix-aware helper) before an order is sent to the API, while still “failing open” if the availability matrix can’t be fetched.

Changes:

• Validate requested speed + session-count against the live NAT Gateway availability matrix during nat-gateway create, returning a validation error that lists supported values when rejected.
• Add unit tests covering matrix rejection (unsupported speed or session count), acceptance (supported pair), and fail-open behavior on matrix fetch failure.
• Bump github.com/megaport/megaportgo to v1.15.0 and add stub methods to the MCR looking glass mock to match the updated SDK interfaces.

Reviewed changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
internal/commands/nat_gateway/nat_gateway_actions.go	Adds matrix-aware speed/session validation during NAT Gateway create (fail-open on fetch/empty).
internal/commands/nat_gateway/nat_gateway_test.go	Adds tests for matrix validation behavior (reject/allow/fail-open).
internal/commands/mcr/mcr_mock.go	Adds stub methods for new SDK MCR looking glass ping/traceroute interfaces to keep tests/build green.
go.mod	Bumps megaportgo dependency to v1.15.0.
go.sum	Updates checksums for the megaportgo v1.15.0 bump.

[penzeliz-megaport]

Reviewed this together with #506/#508/#493 as part of a broader pass. Solid fix overall, and nice catch by the earlier reviewer on the SessionCount == 0 boundary.

One gap I want to flag explicitly: validateNATGatewaySpeedSessionMatrix (nat_gateway_actions.go:114) is only called from CreateNATGateway (nat_gateway_actions.go:64). UpdateNATGateway (nat_gateway_actions.go:245) also accepts --speed/--session-count changes via the update flags but never calls the validator, so:

nat-gateway update <uid> --speed 5000 --session-count 99

still sails past client-side checks straight to the API — the same class of "unsupported speed/session combination reached the API" issue this PR's description says it's closing, just still open on the update path.

Do you want to pull the validation into UpdateNATGateway here, or would you rather ship this as-is (scoped to create) and track update in a follow-up ticket? Happy either way, just want it to be a conscious call rather than an oversight.

[Phil-Browne]

Reviewed this together with #506/#508/#493 as part of a broader pass. Solid fix overall, and nice catch by the earlier reviewer on the SessionCount == 0 boundary.

One gap I want to flag explicitly: validateNATGatewaySpeedSessionMatrix (nat_gateway_actions.go:114) is only called from CreateNATGateway (nat_gateway_actions.go:64). UpdateNATGateway (nat_gateway_actions.go:245) also accepts --speed/--session-count changes via the update flags but never calls the validator, so:

nat-gateway update <uid> --speed 5000 --session-count 99

still sails past client-side checks straight to the API — the same class of "unsupported speed/session combination reached the API" issue this PR's description says it's closing, just still open on the update path.

Do you want to pull the validation into UpdateNATGateway here, or would you rather ship this as-is (scoped to create) and track update in a follow-up ticket? Happy either way, just want it to be a conscious call rather than an oversight.

Submitting a follow-up PR shortly, thanks!