FEAT-#5394: Reduce amount of remote calls for TreeReduce and GroupByReduce operators

[Retribution98]

Apply approaches from PR-7136 for TreeReduce and GroupByReduce operators

What do these changes do?

• first commit message and PR title follow format outlined here

  NOTE: If you edit the PR title to match this format, you need to add another commit (even if it's empty) or amend your last commit for the CI job that checks the PR title to pick up the new PR title.

• passes flake8 modin/ asv_bench/benchmarks scripts/doc_checker.py
• passes black --check modin/ asv_bench/benchmarks scripts/doc_checker.py
• signed commit with git commit -s
• Resolves Reduce amount of remote calls for square-like dataframes #5394
• tests added and passing
• module layout described at docs/development/architecture.rst is up-to-date

[anmyachev]

@Retribution98 do you have any performance numbers?

It's also a good idea to add tests for the new operators, which now work a little differently.

[anmyachev]

Why was the implementation moved to a lower level?

[Retribution98]

It was moved here to avoid duplicating logic, and map_partitions in the partition manager is only used in these cases.

[anmyachev]

Previously, your implementation was also used instead of self._partition_mgr_cls.lazy_map_partitions function, under some condition, but now it is not. Is that how it was intended?

[YarShev]

tree_reduce and groupby_reduce call map_partitions at the partition mgr. That's why @Retribution98 moved the logic there I guess.

[Retribution98]

Yes, I see it. I think lazy map will be better in a lazy pipeline because some partitions may not be calculated further, so this issue is not relevant for this case.

[Retribution98]

@Retribution98 do you have any performance numbers?

@anmyachev
This case is similar to the previous PR, so we can expect the same performance.
Using 112 CPU:

df.count	partitions shape	main	this PR
(Using 112 CPU)	(112, 1)	0.202289	0.19788
	(12544, 1)	13.67759	10.99517
	(112, 112)	4.544378	1.760422

[Retribution98]

It's also a good idea to add tests for the new operators, which now work a little differently.

Since the logic is at a lower level, I modified the test to test this and it covered all cases where map_partitions is used.

[anmyachev]

Using map_axis_partitions function in map_partitions function does not seem obvious and defeats the purpose of map_partitions function, which declares that it applies to every partition.

The dataframe level for choosing a suitable strategy seems more appropriate.

[YarShev]

Since partition mgr rather than core df is designed to play around with partitions, maybe we should just update the docstring?

[Retribution98]

Ok, I added base_map_partitions to keep the simplest implementation, but by default we will use new approaches. Are you agree?

[YarShev]

@Retribution98, could you also check performance for dtypes, which is part of #2751?