Discovery: cap registered presentation size and raise the client response cap

[reinkrul]

Part of #4596 (this PR covers items 1 and 2; streaming and paging remain open for debate there).

What

• Server: registered Verifiable Presentations are limited to 128 KiB. Checked first in Module.verifyRegistration, returned as ErrInvalidPresentation so the server answers 400. Since the same function verifies downloaded entries, clients also ignore oversized entries from a misbehaving server.
• Client: the Discovery Service client reads responses of up to 10 MiB from the operator-configured Discovery Server. The strict HTTP client's response cap is now a per-client setting (WithMaxResponseSize, default unchanged at 1 MiB); every constructor goes through one helper so none can end up without a cap.
• Docs paragraph on the 128 KiB limit; release notes entry under Security.

Why

GET /discovery/{serviceID} returns every entry after the given timestamp in one response, and the client refused anything over 1 MiB, so a service whose list grew past a few hundred entries (about 65 with X509Credentials) could no longer be synced by a new node. Two deliberately padded registrations could do the same for everyone. Details and measurements in #4596.

Sizing

Value	Basis
128 KiB per VP	Measured X509Credential VP with a 3-level G4 chain: 16 KB; production estimate 20 to 27 KB per X509Credential. Leaves room for a presentation carrying several X509Credentials.
10 MiB per response	Largest value that fits a 256 MB node with the current buffered parse (measured about 5x body size transient). At 128 KiB per VP that is 80 fully padded registrations, or roughly 400 to 500 real X509Credential ones.

Testing

• http/client: raised versus default cap against a test server; option applied by all constructors.
• discovery: Register rejects a padded VP with presentation exceeds maximum size of 131072 bytes.

Assisted by AI

[stevenvegt]

64kb seems strict. You said this is around 4 x509 type VCs in a VP? In LSP x Nuts we have an inschrijfVC, mandateVC, OrgVC and others. Some of those are x509 signed. Would 128kb also work without causing problems? Your test start from 10mb right, so perhaps redo them with smaller sizes to see what would be still ok?

[stevenvegt]

how does this VP size limitation relates to presentations used in access token requests? Should we do the same there?

[qltysh]

1 new issue

Tool	Category	Rule	Count
qlty	Structure	Function with many returns (count = 11): verifyRegistration	1

[reinkrul]

how does this VP size limitation relates to presentations used in access token requests? Should we do the same there?

It doesn't, I'll investigate that separately

[reinkrul]

64kb seems strict. You said this is around 4 x509 type VCs in a VP? In LSP x Nuts we have an inschrijfVC, mandateVC, OrgVC and others. Some of those are x509 signed. Would 128kb also work without causing problems? Your test start from 10mb right, so perhaps redo them with smaller sizes to see what would be still ok?

Those aren't credentials that are registered in the discovery service, but access-token-time credentials. We have some use cases that want a separate healthcare provider type-credential, we'll accommodate that comfortably with 64kb cap. If there are use cases that design something that won't fit in the current cap strategy, we can always revise it, but we'll cross that bridge when we get there.