Enforce API payload size limits and query result caps (#1630)

[AkramBitar]

Add size limits to the SQL transaction-store so one huge write or one unlimited query can't overload the database. Fixes the [MED] issue #1630 (denial of service from unlimited resource use, CWE-400 / CWE-770).

• Write limit: AddTokenRequest/AddTransaction/AddMovement reject payloads bigger than a max size (default 4 MiB; 0 turns it off).
• Read limits: QueryTransactions must be given a page size (nil/None are rejected); QueryTokenRequests always adds a LIMIT (default 1000 rows). QueryMovements is left alone because it is used for balance totals.
• Defaults are built in, and can be changed in config (token.storage.maxPayloadSize / maxPageSize) or with the WithMax* options.
• Callers that used to read everything at once now read page by page.

Note for the reviewer

This changes behaviour on upgrade, so it needs a release note:

• The limits are on by default. If the config keys are not set, the defaults (4 MiB / 1000) apply, so existing deployments get them automatically.
• Paging on QueryTransactions cannot be turned off. Setting maxPageSize: 0 only removes the row limit; it still rejects nil/None. Any caller that passed nil to read everything now gets an error and must page instead (see collectAllTransactions / checks.go).

Closes #1630.

[adecaro]

Hi @AkramBitar , thanks for submitting this.

My concern is the following: The storage service has many queries that would require similar constraints. Right now, this opts-based approach works only for the Transactions db.

I would suggest to perform an analysis of the entire storage service to understand which limits need to be put in place and then design a flexible solution to address the issues. A wrapper-based solution could also be interested so that we can stack different layers on top of each other each perform a different function and the bottom one running the actual SQL query.

What do you think?

Thanks 🙏