Bug fix in voting parallel learner

[y-lan]

In our environment, we met a bug that when process GlobalVoting function in voting parallel learner,
if the training data is very sparse and cause train_data_->num_total_features() to be different between workers, the local calculated top_k_splits (from MaxK function) can result in different order between workers, thus cause the upcoming ReduceScatter to hang permanently for incorrect send/recv data size.

Sort the calculated top_k_splits seems a quick solution for this.

[guolinke]

Thanks!

[StrikerRUS]

@guolinke Shouldn't stable_sort be used here? #1739

[guolinke]

thanks @StrikerRUS , stable_sort will be better, for there may exist some duplicated splits from multi-nodes.

[StrikerRUS]

@guolinke Oh, just noticed that 3 other files in the repo contain sort: https://github.com/microsoft/LightGBM/search?q=%22std%3A%3Asort%22&unscoped_q=%22std%3A%3Asort%22

[guolinke]

@StrikerRUS these sorts are okay, for:

1. ParallelSort is only used for auc evaluation, it will not affect the model training.
2. the rest of them sort the index, which will produce unique results.