perf(weee): cache parent lookups in ConfigurableVariationAttributePriority (#40642)

[lbajsarowicz]

Description

The plugin invoked by Tax::getProductWeeeAttributes iterated every
configurable parent of every child product and re-loaded each parent
via the product repository on every invocation. On category and search
listing pages this fanned out into a tight N+1 — the same configurable
parent was loaded N times for its N visible variants — and the loop
overwrote \$result on every iteration instead of returning the first
non-empty match. The reporter's profiling on 2.4.8-p4 attributes ~30%
of Calculator::getAmount wall time to this path.

Added per-request memoisation keyed by:

• child id -> parent ids (skip getParentIdsByChild on repeats),
• parent id + scope signature (shipping/billing/website/calculate/round)
  -> weee attributes (skip repeated parent product loads across variants
  of the same configurable).

Bail out as soon as a non-empty result is found, and skip the loop
entirely when the original result already has data. Implement
ResetAfterRequestInterface so the caches do not leak across web
requests in single-process containers.

Fixes #40642

Fixed Issues

• Fixes [Performance Regression] Severe price calculation latency in 2.4.8-p4 related to Weee Plugin and Configurable Products #40642: [Performance Regression] Severe price calculation latency in 2.4.8-p4 related to Weee Plugin and Configurable Products

Performance Impact

Reproduced on a catalog of configurables with 6 child variants each.
With Weee tax enabled and no override on children:

• Before: getProductWeeeAttributes triggers productRepository::getById
  • Tax recomputation per variant per render -> O(N * M).
• After: parent lookup happens once per parent per request, scope-aware
  cache reuses across variants -> O(unique parents).

Manual testing scenarios

1. Enable Weee tax (Stores > Configuration > Sales > Tax > Fixed Product Taxes).
2. Create a configurable product with several variants. Leave the Weee
   attribute populated only on the parent.
3. Render a category page containing the configurable. Profile with
   Blackfire / Xdebug / SPX: getProductWeeeAttributes calls collapse
   to one per unique parent for the request.

Contribution checklist

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All automated tests passed successfully (269 Weee unit + 3 new)
• Changes to the codebase comply with technical guidelines

[m2-assistant]

Hi @lbajsarowicz. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[lbajsarowicz]

@magento run all tests

[lbajsarowicz]

@magento run all tests