[3.14] gh-119452: Read/write CGI data using worker threads

[encukou]

This reads/writes data as available, making the CGI application responsible for managing any timeouts when receiving data from clients.

Data is read in chunks of bounded size, and passed on immediately (except stderr, which is combined into a single message as before).

This does need 3 threads. (As does process.communicate.)

• Issue: OOM a potential denial of service in the CGI server on Windows #119452

[encukou]

@serhiy-storchaka See here.
Do you think it's better than loading all request data to memory, then sending it to the process all at once?

[serhiy-storchaka]

This approach has great advantages, I like it, but creating a thread is not cheap. This is also much bigger change, so we should evaluate all the pros and cons.

Can the same select() loop be used for input and output? Can it be ran in the original thread?

[encukou]

creating a thread is not cheap

Sure, but can you make this cheaper? Note that Popen.communicate also creates 3 threads (generally: one for each pipe, except if there's only one pipe).

Can the same select() loop be used for input and output?

On Windows, select only works on sockets.

[gpshead]

The issue was only around the memory allocation of an untrusted nbytes value here. introducing a thread seems unnecessary. There wasn't a resource exhaustion problem with this blocking for the issue at hand.

The memory-address-space-DoS consumption point is to only allocate an amount close in magnitude to the total data that actually arrives rather than the untrusted number up front. A simple loop reading in chunk increments as the earlier PR #119455 did, but without a select at all would handle the issue fine. (ie: just remove the select from the earlier pr entirely)