Support low-ulimit platforms in Python runtime

[lkingland]

The Python function runtime should raise its soft ulimit for open files
to match the hard limit at startup. Go and Java runtimes already do this
automatically. Without it, the Python runtime fails under load on
platforms with a low default soft limit (e.g. 1024).

The fix belongs in the middleware startup path.

Related: SRVOCF-788

[Ankitsinghsisodya]

/assign

[Ankitsinghsisodya]

I picked this up and wanted to share what I did, including a mistake I made along the way.

---

First attempt — wrong layer

I put the fix in the scaffolding templates (templates/python/scaffolding/instanced-http and instanced-cloudevents) in knative/func. The logic was sound — raise the soft open-file limit to the hard limit at startup, handle RLIM_INFINITY correctly, guard against non-Unix platforms, add tests. But the location was wrong.

Scaffolding is generated glue code — it is the wrong owner for runtime startup logic. The fix also ends up duplicated across both scaffolding variants, and any user who customises main.py may not get it. I opened #3612 for this and got review feedback pointing out these issues.

---

Correct fix — middleware layer

The right place is inside serve() in the func-python library itself, which is what the issue description was pointing at with "the middleware startup path". A fix there lives in one place, has a clear owner, and is consistent with how Go and Java handle the same thing in their runtimes.

I have opened knative-extensions/func-python#83 with the fix in the correct location — a _raise_nofile_limit() call at the top of serve() in both http.py and cloudevent.py, extracted into a shared _ulimit.py module with tests covering the normal case, RLIM_INFINITY, non-Unix platforms, and permission errors.

#3612 is now closed.

---

Once knative-extensions/func-python#83 merges and a release is cut, I will open a follow-up PR here to bump the pinned func-python version in the scaffolding pyproject.toml files to close this issue out.