Add containers_pid_namespace compatibility flag

[gpanders]

When set, this compatibility flag instructs the containers runtime to start the user's container in a separate PID namespace. Eventually this will become the default (past some yet-to-be-determined compatibility date).

---

Per @danlapid's suggestion, this follows the pattern used by neededByFl to annotate compatibility flags specifically needed for the containers service. We'll use this annotation in Edgeworker to send only the required compatibility flags to the ContainerService from the actor.

Part of CC-6789

[kentonv]

Since we talk to the containers service over capnp, it's probably cheaper and easier to just send the entire CompatibilityFlags struct over capnp to the container. Sending even one string name probably ends up being larger than sending the entire bitfield.

So I don't think we actually need this annotation and I definitely don't think we should be sending string names to the container service.

[kentonv]

(The neededByFl annotation is a bit different since we talk to FL over HTTP, not capnp, and sending an encoded bitfield would be awkward there. Though perhaps we should have done it that way as the string names are still quite bulky in that case too...)

[gpanders]

Well that makes this PR much simpler then :) Updated

[kentonv]

Well, there's no point in adding the compat flag if it's not actually being passed to containers. So I'd like to see that mechanism added to this PR. That should be part of the RPC interface, right?

[gpanders]

Yes but that is done in edge runtime, not workerd IIUC? I have a separate PR for that that I will open soon.

I did forget to implement the PID namespace feature for local dev, which I'll do now.

[kentonv]

The edge runtime makes the initial connection to the container service well before it has actually loaded the worker, so compat flags wouldn't be available yet from there. I think the best place to put the flags is going to be in StartParams.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 0% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 70.51%. Comparing base (dd7a515) to head (d31fd31).
⚠️ Report is 28 commits behind head on main.

Files with missing lines	Patch %	Lines
src/workerd/server/container-client.c++	0.00%	5 Missing ⚠️
src/workerd/api/container.c++	0.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6063      +/-   ##
==========================================
+ Coverage   70.38%   70.51%   +0.12%     
==========================================
  Files         408      408              
  Lines      108811   108791      -20     
  Branches    18000    17995       -5     
==========================================
+ Hits        76591    76711     +120     
+ Misses      21415    21286     -129     
+ Partials    10805    10794      -11     

☔ 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

The generated output of @cloudflare/workers-types matches the snapshot in types/generated-snapshot 🎉

[codspeed-hq]

Merging this PR will not alter performance

✅ 70 untouched benchmarks
⏩ 129 skipped benchmarks¹

---

_{Comparing ganders/CC-6790 (d31fd31) with main (3274cc9)}

Footnotes

1. 129 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[kentonv]

Sorry to suggest yet another redesign, but per my comment above, I think you are going to need to pass this in StartParams. In the edge runtime, it won't be feasible to pass the compatibility flags to the place where the container is first requested, since the worker hasn't necessarily been loaded yet at that point.