api: keep the OpenAPI validator off upload bodies so kin-openapi can be upgraded

[drewmaring]

Related: #9409 (the regression this removes), #10505 (the kin-openapi bump this unblocks)

Change Description

Background

Since #9408 lakeFS pins github.com/getkin/kin-openapi at 0.131.0 because 0.132+ made uploads read the whole object into memory. That pin now carries a CRITICAL advisory (GHSA-r277-6w6q-xmqw) and two HIGH ones, and blocks the dependabot bump in #10505. Root-causing the memory growth showed it is not in request-body validation at all, so it can be fixed on the lakeFS side without waiting for kin-openapi.

Bug Fix

1. Problem — with kin-openapi ≥ 0.132, a 300 MB uploadObject drives the lakefs process from ~215 MB to ~990 MB RSS, and an unauthenticated upload is read in full before the 401 (lakeFS memory grows while upload object #9409).
2. Root cause — openapi3filter.ValidateSecurityRequirements reads the entire request body up front so that an AuthenticationFunc can re-read it (openapi3filter: don't consume request body in AuthenticatorFunc getkin/kin-openapi#1064). It runs before request-body validation, so Options.ExcludeRequestBody and the x-validation-exclude-body extension never get a chance to skip it.
3. Solution — in validateRequest, for routes marked x-validation-exclude-body and for any application/octet-stream / multipart/form-data request, give the validator a body-less clone of the request (Body = http.NoBody). The handler still receives the original request and streams the body to the block store as before. lakeFS uses NoopAuthenticationFunc, so nothing in the validator needs the body. JSON bodies are unchanged and still validated.

Testing Details

• New pkg/api/validate_request_test.go: the validator reads zero bytes of an upload body and the handler still receives all of it; a malformed JSON body still yields 400. Fails on kin-openapi 0.149.0 without the change, passes with it (and on 0.131.0).
• go test ./pkg/api -run TestValidateRequest, go vet ./pkg/api, gofmt clean.
• Memory measured on a built image (lakefs run --quickstart, 300 MB uploadObject, VmRSS of PID 1 sampled during the upload): v1.86.0 217 MB peak; v1.86.0 + kin-openapi 0.149.0 990 MB; v1.86.0 + kin-openapi 0.149.0 + this change 215 MB. Unauthenticated upload with the change: 401 in ~6 ms, no growth.

This PR deliberately does not bump kin-openapi itself, so it is safe on the current pin; with it merged, #10505 (or a fresh bump to 0.149.0, which also needs apache/thrift 0.24.0 and grpc 1.83.1 for the remaining advisories) should be clear to land.

Breaking Change?

No. Behaviour only changes for requests whose body the validator was already told to skip.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Drew Maring seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}