fix: Add maxBuffer option and enforce MAX_STRING_LENGTH on stdout and stderr by default [EXP-02]

[kitten]

Summary

Note

This attempts to avoid breaking changes, and is hand-written, since it's a thin line to walk, that didn't lead LLMs to write clean code. It's still LLM reviewed though

The string captured for stdout and stderr implicitly stringifies chunks, which can crash the process in two ways:

• the maximum string length can be exceeded by this concatenation
• the process memory can be exhausted with huge outputs from a command

By default, we should be enforcing the MAX_STRING_LENGTH. Existing calls of spawnAsync will now enforce this limit and will issue an error with the truncated strings when this limit is exceeded. The stdout and stderr strings are built lazily. The error we throw for this case will carry the truncated outputs.

When maxBuffer is set explicitly, we enforce this limit explicitly and reject the spawnAsync promise explicitly.

This was done to limit disruption to downstream consumers. However, it's still necessary for us to update call-sites that are uncontrolled/unbounded with an explicit maxBuffer, if we're calling spawnAsync on any process that:

• is user-controlled/uncontrolled (can force a crash)
• can produce huge outputs that can still cause memory to be consumed eagerly

Set of changes

• Add maxBuffer option that, if set, rejects with a code: 'ERR_CHILD_PROCESS_STDIO_MAXBUFFER' error when the buffer size is exceeded
• Collect sliding chunk window for stdout and stderr chunks
  • Note: This also fixes byte encoding errors since we concatenate later before stringifying
• Add lazy stdout and stderr getters that build the output string
  • When maxBuffer is not set explicitly, they may error lazily when the maximum size is reached now, which would've previously resulted in the max string length being exceeded accidentally during concatenation
• Drive-by fix: Fix completionListener not being attached to exit when stdio is ignored and ignoreStdio isn't true

[kitten]

Checking against expo/expo CI here: expo/expo#45998
I'd expect to see zero failures, but better to be safe than sorry