Request size limiter

[zealsham]

This pr addresses #941, it implements a body size limit layer to reject request whose size is greater than 65536 bytes.

Pull Request Checklist

Please confirm the following before requesting review:

• I have disclosed my use of
  AI
  in the body of this PR.
• I have read CONTRIBUTING.md and rebased my branch to produce hygienic commits.

[coveralls]

Pull Request Test Coverage Report for Build 23367463396

Details

• 4 of 5 (80.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.004%) to 84.121%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
payjoin-mailroom/src/directory.rs	4	5	80.0%

Totals
Change from base Build 23300212261:	-0.004%
Covered Lines:	10648
Relevant Lines:	12658

---

💛 - Coveralls

[spacebear21]

Since we are applying the 7168 uniformly across v1 and v2 requests, I don't see the value in extracting v1 routing into its own router? The current approach is also confusing because v1 routing is now seemingly happening in two places, both in v1_post_handler and in directory Service::serve_request

[zealsham]

Since we are applying the 7168 uniformly across v1 and v2 requests, I don't see the value in extracting v1 routing into its own router? The current approach is also confusing because v1 routing is now seemingly happening in two places, both in v1_post_handler and in directory Service::serve_request

I noticed that applying the limiter globally breaked a lot of the integration test. Because the v1 sender never touches the ohttp relay, applying the limiter globally also breaks v2 that communicates via ohttp. my work around was extracting the v1 router (which only applies the limiter) and then route the request to the v1 handlers in the directory.

if we want to still keep the manual size check rather than using tower_http limiter, i can rename v1_max_buffer to max_payload_size , add a size check in post_fallback_v1 and then update the branch name and commit mesage too

[nothingmuch]

if all handled request bodies have a fixed size bound it might make sense to use an array type to pass them around as this could potentially simplify some conversions, perhaps an argument for fixing the size at 7168

[nothingmuch]

@DanGould has argued correctly that this can be closer to 8104 bytes, but there's a variable element of overhead in OHTTP requests relating to the request URI that makes this a bit tricky. i'm personally happy with this as the limit