refactor splitting

[rukai]

Attempt at DRY'ing up the splitting logic, seeing if its worth it or not.

fetch splitting deviates too far from the logic of the rest of the splitting methods, so I've not attempted to implement it with the new RequestSplitAndRouter trait.

Since this only saves 40 lines, normally I would say its not worth the complexity of traits here.
However there are two reasons I think we should go ahead with this:

1. The logic that is DRY'd is actually pretty tricky to get right, hence why it has so many comments explaining whats going on. So having that implemented only once is quite valuable, on the other hand while the RequestSplitAndRouter trait implementations take ~25 lines each to implement, they are very difficult to get wrong since its mostly just specifying types so the type checker will catch anything wrong here.
2. we are going to need to implement message splitting for at least 2 more message types and likely more. So this will save more lines in the future.

[codspeed-hq]

CodSpeed Performance Report

Merging #1771 will improve performances by 13.59%

_{Comparing rukai:refactor_splitting (678118c) with main (a3cef2c)}

Summary

⚡ 1 improvements
✅ 38 untouched benchmarks

Benchmarks breakdown

	Benchmark	main	rukai:refactor_splitting	Change
⚡	encode_system.local_result_v5_no_compression	105.7 µs	93 µs	+13.59%