Handle FT.PROFILE response (impacted with Coordinator) processing with "ProfilingInformation"

[atakavci]

Closes/Fixes #312

FT.PROFILE returns a two-element array reply. The first element contains the results of the provided FT.SEARCH or FT.AGGREGATE command. The second element contains information about query creation, iterator profiles, and result processor profiles.
Profiling details part of response has changed to contain information from shards and coordinator.
Previous and new response layouts given below;
To handle this change and possible future iterations, ProfilingInformation introduced as part of return type, which provides a more generic type and leave the choice of how the results are consumed to the developers;

        var profileSearch = await ft.ProfileSearchAsync(index, q);
        var searchRes = profileSearch.Item1;
        var searchDet = (RedisResult[])profileSearch.Item2.Info;

Previous response layout

"FT.PROFILE" "TEST_INDEX" "SEARCH" "QUERY" "hello|world" "NOCONTENT"
1) 1) (integer) 2
   2) "1"
   3) "2"
2) 1) 1) Total profile time
      2) "0"
   2) 1) Parsing time
      2) "0"
   3) 1) Pipeline creation time
      2) "0"
   4) 1) Iterators profile
      2)  1) Type
          2) UNION
          3) Query type
          4) UNION
          5) Time
          6) "0"
          7) Counter
          8) (integer) 2
          9) Child iterators
         10)  1) Type
              2) TEXT
              3) Term
              4) hello
              5) Time
              6) "0"
              7) Counter
              8) (integer) 1
              9) Size
             10) (integer) 1
         11)  1) Type
              2) TEXT
              3) Term
              4) world
              5) Time
              6) "0"
              7) Counter
              8) (integer) 1
              9) Size
             10) (integer) 1
   5) 1) Result processors profile
      2) 1) Type
         2) Index
         3) Time
         4) "0"
         5) Counter
         6) (integer) 2
      3) 1) Type
         2) Scorer
         3) Time
         4) "0"
         5) Counter
         6) (integer) 2
      4) 1) Type
         2) Sorter
         3) Time
         4) "0"
         5) Counter
         6) (integer) 2

New response layout

 "FT.PROFILE" "TEST_INDEX" "SEARCH" "QUERY" "hello|world" "NOCONTENT"
1) 1) (integer) 2
   2) "1"
   3) "2"
2) 1) Shards
   2) 1)  1) Total profile time
          2) "0"
          3) Parsing time
          4) "0"
          5) Pipeline creation time
          6) "0"
          7) Warning
          8) None
          9) Iterators profile
         10)  1) Type
              2) UNION
              3) Query type
              4) UNION
              5) Time
              6) "0"
              7) Counter
              8) (integer) 2
              9) Child iterators
             10) 1)  1) Type
                     2) TEXT
                     3) Term
                     4) hello
                     5) Time
                     6) "0"
                     7) Counter
                     8) (integer) 1
                     9) Size
                    10) (integer) 1
                 2)  1) Type
                     2) TEXT
                     3) Term
                     4) world
                     5) Time
                     6) "0"
                     7) Counter
                     8) (integer) 1
                     9) Size
                    10) (integer) 1
         11) Result processors profile
         12) 1) 1) Type
                2) Index
                3) Time
                4) "0"
                5) Counter
                6) (integer) 2
             2) 1) Type
                2) Scorer
                3) Time
                4) "0"
                5) Counter
                6) (integer) 2
             3) 1) Type
                2) Sorter
                3) Time
                4) "0"
                5) Counter
                6) (integer) 2
   3) Coordinator
   4) (empty array)

[slorello89]

Since this is a breaking change, the new structure should be more complete IMO, you could include the raw result as well so you don't need a code change to get to the latest view of the profiler result, but I would at least expect to see the new API to be fully mapped in the response.

[slorello89]

There doesn't seem to be a lot of value-add here (in fact I think the old structure is cleaner), also - this is a major breaking change, so this really ought to be fleshed out much more.

[atakavci]

hi @slorello89, the intention is to avoid client API from throwing an exception due to response layout that Redis server provides across different versions. Considering, for a consumer app, server version would be updated first(most of the time), a fully mapped return type leaves consumer apps with no use of profile command when a breaking change on server side. Another compelling reason to not fully map is that command use cases are debugging purposes mostly.