Extract the logic for storing pending/loaded records in lazy_state in GraphQL aggregators to separate concern

The following discussion from !45518 (merged) should be addressed:

• @splattael started a discussion:

  Non-blocking question It seems we are using the very same pattern "pending/loaded" pattern several aggregates already and this seems a bit repetitive and low-level when using two (nested) Hashes and Sets (see https://wiki.c2.com/?PrimitiveObsession).

  I was wondering if we can simplify and streamline the resolution of records and unify the approach by extracting the logic into a class/module/concern? 🤔

  • @lazy_state = query_ctx[:lazy_user_notes_count_aggregate] ||= {
  • @lazy_state = query_ctx[:lazy_block_aggregate] ||= {
  • @lazy_state = query_ctx[:lazy_vulnerability_statistics_aggregate] ||= {
  • @lazy_state = query_ctx[:lazy_epic_aggregate] ||= {

  Can you open a follow-up issue to continue the discussion? 🙏

Implementation plan

• backend Create a base class for aggregations by extracting common logic from all lazy aggregate classes mentioned above
• backend Update all the classes mentioned above in ee/lib/gitlab/graphql/aggregations/ by using inheritance (using super) to DRY up (e.g., class LazyBlockAggregate < BaseAggregate)