add network policy resource to catalog

[jubrad]

• adds durable and mem network policy types
• introduces builtin network policy and network_policies table.

Motivation

Adds Network policy resources to catalog. Also adds a new builtin NetworkPolicy, and a new mz_internal.network_policies table. Part of https://github.com/MaterializeInc/database-issues/issues/4637

Tips for reviewer

Checklist

• [ ] This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• [ ] This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• [ ] If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• [ ] If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• [ ] If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

[shepherdlybot[bot]]

Mitigations

Completing required mitigations increases Resilience Coverage.

• [x] (Required) Code Review 🔍 Detected
• [ ] (Required) Feature Flag
• [x] (Required) Integration Test 🔍 Detected
• [ ] (Required) Observability
• [ ] (Required) QA Review
• [ ] (Required) Run Nightly Tests
• [x] Unit Test 🔍 Detected

Risk Summary:

The pull request has a high risk score of 83, driven by predictors such as the average line count in files and executable lines within files. Historically, PRs with these predictors are 157% more likely to cause a bug compared to the repository baseline. Additionally, the repository's observed and predicted bug trends are both increasing, and 12 modified files are identified as recent hotspots.

Note: The risk score is not based on semantic analysis but on historical predictors of bug occurrence in the repository. The attributes above were deemed the strongest predictors based on that history. Predictors and the score may change as the PR evolves in code, time, and review activity.

Bug Hotspots: What's This?

File	Percentile
../src/main.rs	94
../memory/objects.rs	99
../catalog/builtin_table_updates.rs	96
../catalog/state.rs	94
../src/catalog.rs	95
../coord/ddl.rs	93
../durable/persist.rs	98
../src/builtin.rs	91
../src/plan.rs	91
../objects/serialization.rs	92
../src/catalog.rs	94
../sequencer/inner.rs	98

[jubrad]

Are all roles assigned the MZ_DEFAULT_NETWORK_POLICY by default?

No, when we move the system_var to network_policy which will just point to a NetworkPolicyId, any role that does not have a policy would get validated against this policy something like:

// validate users ip in handle_startup
role
  .network_policy()
  .unwrap_or(catalog.get_network_policy(system_config.default_network_policy()))
  .validate_ip(ip);

[ParkMyCar]

No, when we move the system_var to network_policy which will just point to a NetworkPolicyId, any role that does not have a policy would get validated against this policy something like:

// validate users ip in handle_startup
role
  .network_policy()
  .unwrap_or(catalog.get_network_policy(system_config.default_network_policy()))
  .validate_ip(ip);

I see! My only concern with this is the system var can be modified by the user, but a builtin policy cannot. I might be misunderstanding the way this works though!