Don't optimize the aggregation graph during `connect_child` (#100147)
If a task completion enqueues too much optimization work we record an
`optimization_pending` flag so that it can be processed in a later
attempt.
However `connect_child` calls `increase_active_count` which attempted to
flush pending optimizations. This could greatly slow down execution by
enqueueing graph management in the hot `connect_child` path. But also it
could be self defeating, since we would optimize a task, and then add it
as a child, which would (on task_completion) potentially add a new
`upper` which could trigger more optimizations.
For `Module::ident` this could be pathological since a lot of large
tasks call it for all modules (e.g. to compute module ids), each of
these could enqueue optimization work and then the next task (e.g. parts
of asset tracing) could both complete optimizations and enqueue new
ones.
This severely punished `project_feature_usage` which was single threaded
and thus did a lot of expensive work.
next.js
0fc57c31 - Don't optimize the aggregation graph during `connect_child` (#100147)
