feat: Add ability to explain sumNode attribute(s).

[shahzadlone]

Relevant issue(s)

Resolves #482.

Description

Adds the attributes for sumNode to be included in the returned explain graph response.
In this PR we are introducing 3 attributes:

1. fieldName
2. childFieldName
3. filter

Example:

Request:

query @explain {
  author {
    name
    _key
    TotalPages: _sum(books: {field: pages})
  }
}

Response:

{
  "explain": {
    "selectTopNode": {
      "sumNode": {
        "sources": []{
		  {
		    "fieldName":      "books",
			"childFieldName": "pages",
			"filter":         nil,
		  }
		},
        "selectNode": {
          "filter": null,
          "typeIndexJoin": {
            "joinType": "typeJoinMany",
            "rootName": "author",
            "root": {
              "scanNode": {
                "collectionID":   "3",
                "collectionName": "author",
                "filter":         null,
                "spans": []{
                  {
                    "start": "/3",
                    "end":   "/4",
                  }
                }
              }
            }
            "subTypeName": "books",
            "subType": {
              "selectTopNode": {
                "selectNode": {
                  "filter": null,
                  "scanNode": {
                    "collectionID":   "2",
                    "collectionName": "book",
                    "filter":         null,
                    "spans": []{
                      {
                        "start": "/2",
                        "end":   "/3",
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

Tasks

• I made sure the code is well commented, particularly in hard-to-understand areas.
• I made sure the repository-held documentation is changed accordingly.
• I made sure the pull request title adheres to the conventional commit style (the subset used in the project can be found in tools/configs/chglog/config.yml).
• I made sure to discuss its limitations such as threats to validity, vulnerability to mistake and misuse, robustness to invalidation of assumptions, resource requirements, ...

How has this been tested?

Integration tests locally and only CI. Specifically make test.

Specify the platform(s) on which this was tested:

• Manjaro Flavor of Arch Linux Running in WSL2 on Windows 11

[fredcarle]

Approving assuming you address the 2 points I've raised. Seems like you'll see those on all your explain PRs 😅.

[AndrewSisley]

couple of minor comments on the tests, otherwise looks good!

[codecov]

Codecov Report

Merging #559 (6b355fe) into develop (3957381) will increase coverage by 0.10%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop     #559      +/-   ##
===========================================
+ Coverage    56.58%   56.69%   +0.10%     
===========================================
  Files          121      121              
  Lines        14082    14104      +22     
===========================================
+ Hits          7969     7996      +27     
+ Misses        5421     5416       -5     
  Partials       692      692              

Impacted Files	Coverage Δ
query/graphql/planner/sum.go	81.69% <100.00%> (+6.89%)	⬆️

[AndrewSisley]

Approved, and thanks for the test expansion. Added a small thought RE one of the props, but is optional

[AndrewSisley]

thought (non-blocking): I'm not sure this should be present - it should only reach here if summing an inline array, which doesn't have this prop available in the query syntax. Your call though, no strong feelings.

[shahzadlone]

thought (non-blocking): I'm not sure this should be present - it should only reach here if summing an inline array, which doesn't have this prop available in the query syntax. Your call though, no strong feelings.

That is a reasonable thought, I raised the same question in my head too while implementing it. Thinking about it a bit, I was still unsure what the best route was so I decided to go with this approach (leaving the empty child as nil) because of the following reasons:

1. This would till accurately show if the child is empty or not(as you mentioned will be only for the inline array case).

2. So far for every explained node the number of attributes that are dumped doesn't change depending on the underlying value of the attribute that is being dumped, so this keeps it consistent to always dump a specific number of attributes.

3. Even though the current implementation is technically called Explain it is technically a Simple + Verbose explain (from the future roadmap) i.e. @explain(type: 'simple', verbose: true) which will also be the default explain: i.e. @explain. So in that light these varying attributes can be left for the work for the verbose: false feature which would omit the nil fields (here and in filter for example).