Ability to stream SEARCH results

[danieleggert]

For FETCH responses, we already do streaming.

The result of a SEARCH / UID SEARCH could return a very large response, and as such, it would be good to stream those, too.

E.g. running UID SEARCH UID 1:* (in order to detect deleted messages) on a mailbox with 100,000 messages, will return a single response with 100,000 UIDs:

I have an Inbox with ~12k messages, where I get a response with 81,781 bytes:

A3 UID SEARCH UID 1:*
* SEARCH 1 2 3 4 5 11 12 13 14 26 31 33 42 43 45 50 58 59 68 69 70 73 74 92 94 163 174 177 181 182 183 184 187 188 189 190 193 198 201 211 241 242 243 246 247 248 249 250 253 258 259 260 261 262 263 265 266 269 271 287 288 289 290 294 299 300 303 312 313 314 315 316 317 324 325 326 335 338 359 398 399 400 401 652 678 693 708 714 716 717 726 727 730 733 738 739 743 745 783 787 792 793 794 797 798 799 800 809 810 815 817 820 822 823 830 831 832 839 844 859 866 891 911 930 1029 1043 1080 1081 1082 1083 1084 1086 1089 1090 1091 1110 1130 1161 1162 1166 1168 1172 1173 1175 1179 1182 1186 1191 1194 1201 1203 1207 1213 1217 1220 1221 1268 1269 1272 1297 1301 1302 1332 1362 1363 1367 1369 1370 1371 1372 1373 1375 1376 1392 1401 1438 1446 1449 1469 1470 1472 1473 1482 1493 1494 1498 1520 1525 1529 1530 1531 1532 1533 1536 …
``
For 100,000 messages, we’d thus expect a response with > 800 KB.

If we could _pack_ these more densely, and decode each network packet separately, we’d need less peak memory.

[danieleggert]

Not urgent at all.