[jvm-packages] Fix partition related issue

[jinmfeng001]

In jvm package, there are some partition related issues.

1. For ranking case(group column defined), it assumes that the input data is partitioned by group column and the data for the same group is in the same partition as aggByGroupInfo. But the assumptionis not guaranteed. In our real prodution use case, we have to repartition the input dataset by the group column and set the partition number same as the number of worker to bypass the repartition. Otherwise our ranking model perform extremely bad.
2. When checkpoint is enabled, needDeterministicRepartitioning is set to true. And the data set will be repartitioned base on the attached key. But for the ranking case the repartition key should be the group column, otherwise the data with the same group will be shuffled to different partitions which broken the ranking model assumption. I don't see any reasons to only make xgboost deterministic when checkpoint is enabled, i think we can make xgboost always being deterministic, and partition the data based on the group column when it's defined and on the row hash when it's not defined.

After this fix, it's gauranteed that data with same group are in the same partition, and xgboost is always deterministic no matter checkpoint is enabled or not.

[trivialfis]

Hi @jinmfeng001 , thank you for working on the ranking implementation (and other JVM package issues). I will look into this after 2.0 is released. Please note that we have revised the LTR implementation in 2.0, which doesn't affect the current status of the JVM package, but it brings a couple to-do items for us to explore and might create conflicts with changes made in this PR:

• XGBoost might group and sort the samples internally based on query IDs.
• XGBoost might change the strategy for training LTR models on distributed systems.