Memoize ContextHandler::getMatchingContexts() per operand pair

Problem/Motivation

ContextDefinition::isSatisfiedBy() is pure with respect to its two operands — the same definition asked about the same context object cannot answer differently within a request — but it is expensive: it builds constraint objects, may generate sample entities through EntityContextDefinition::getSampleValues(), and runs the validator.

Callers ask it the same question repeatedly. Layout Builder is the extreme case: LayoutBuilderEntityViewDisplay::buildSections() calls SectionStorageManager::findByContext() once per rendered entity, which filters every section storage definition against every available context — and LazyContextRepository hands out the same runtime context objects each time, so the answers are already known.

Steps to reproduce

Measured with XHProf on a Drupal 11.3 site with 274 modules (109 available contexts), on a page rendering 137 Layout Builder entities:

• 137 findByContext() calls produced 76,720 isSatisfiedBy() calls
• 5,460 ms inclusive, 59.6% of the request's wall time
• 28,496 constraint objects built, 15,207 validator runs

Proposed resolution

Memoize the answer per operand pair.

This is the same treatment #2994550 gave the sibling method filterPluginDefinitionsByContexts(), which memoizes checkRequirements() behind a hash of the serialized context definitions and explicitly does not touch getMatchingContexts().

That key does not transfer here. Serializing the operands of this method breaks three existing ContextHandlerTest cases with "Serialization of 'Closure' is not allowed", so the MR keys on object identity instead, in a WeakMap holding both operands. That is also the stricter guarantee: it assumes nothing about constraint semantics, only that asking the identical pair twice gives the identical answer. Holding both operands as weak references matters — without a reference PHP may reuse the object id of a collected object, and a later pair would read a stale answer.

The WeakMap is created on first use rather than in a constructor, so the class signature stays as it is for subclasses.

Test coverage

Two cases in ContextHandlerTest, both failing without the change:

• testGetMatchingContextsMemoizesTheAnswer() — a definition is asked about a context once across repeated calls.
• testGetMatchingContextsKeepsAnswersApart() — a second definition answers the other way round for both contexts, so an answer shared between definitions or between contexts surfaces as a wrong return value and not only as a call count.

Related issues

• #2994550 established this pattern in the sibling method.
• #2981889 made isSatisfiedBy() itself cheaper by disabling recursive validation. The measurement above is on a version that already has that fix.
• #3043319 reported this call path and was closed as a duplicate of #2981889.