[python-package] make _InnerPredictor construction stricter

[jameslamb]

Proposes some changes to make the construction of an _InnerPredictor:

• replacing constructor arguments booster_handle and model_file (and the corresponding if-else block) with class methods .from_booster() and .from_model_file()
• removing Booster._to_predictor(), in favor of direct use of those class methods
• avoiding initializing Booster._handle to None in Booster.__init__() (so that mypy can confirm that it's never possible for it to be None)
• removing _InnnerPredictor.num_total_iteration, in favor of just calling _InnerPredictor.current_iteration() in the one place that was using _InnnerPredictor.num_total_iteration

These changes reduce unnecessary duplication, make it easier to understand the relationship between _InnerPredictor and Booster, and reduce the risk of "silently fell back to a default value" types of bugs by making these internal APIs stricter (no default values and mostly don't accept None).

Notes for Reviewers

Now that v4.0.0 is almost out (#5952), next I'm looking to spend some time on making it easier for outside contributors to contribute to LightGBM. This is the first in a series of PRs I'm planning to make LightGBM's internals stricter and easier to understand.

How I tested this

In addition to the unit tests, confirmed that this does not introduce any new errors from mypy by running the following on both master and this branch.

sh ./.ci/lint-python.sh

[jameslamb]

As of #5947, there is no path through lightgbm's public API which would allow a user to overwrite Booster._handle with None.

Making these changes to ensure it's never None avoids the need to do if {booster}._handle is not None types of checks in _InnerPredictor.from_booster().

[github-actions]

This pull request has been automatically locked since there has not been any recent activity since it was closed. To start a new related discussion, open a new issue at https://github.com/microsoft/LightGBM/issues including a reference to this.