We should not be generating the plan summary string for every find operation, as it is expensive to generate.

The plan summary string is currently used for the server log output, and is made available for introspection with db.currentOp(). We should certainly preserve the use case of exposing the plan summary in the server log output. If we do want to preserve the use case of exposing the summary string for slow queries in db.currentOp(), we could consider an approach where PlanExecutor::getNext() generates the summary string after N work calls, or after the root stage's "approximate timer" exceeds the global slowMS value.