Incorrect best_ntree_limit.

[trivialfis]

The fix #6579 got in 1.3.2 was actually wrong. Here's a brief summary:

The old (before fix) best_ntree_limit ignores the num_class parameters, which is incorrect. In before we workarounded it in c++ layer to avoid possible breaking changes on other language bindings. But the Python interpretation stayed incorrect. The PR fixed that in Python to consider num_class, but didn't remove the old workaround, so tree calculation in predictor is incorrect, see PredictBatch in CPUPredictor.

Proposal: Revert the fix for now, and deprecate the parameter in next release.

cc @pseudotensor @hcho3

[trivialfis]

R binding is consistent with the old Python behavior, see callbacks.R.

[hcho3]

I agree that we should deprecate ntree_limit argument and encourage the use of model slicing. For now, let's revert the change to minimize the risk of breaking the release.

@trivialfis Do you plan to make another release? Should it be 1.3.2.post0 (hot-fix) or 1.3.3 (another patch release)?

[trivialfis]

I will make a 1.3.3 release on Python side. Thinking about how to add a test that can check for an incorrect behavior.

[trivialfis]

PR in #6616 . Will backport.