[FEA] Add GPUTreeSHAP to cuML explainer module (experimental)

[hcho3]

Addresses #4110

This is an experimental prototype. For now, it supports:

• XGBoost models with numerical splits
• cuML RF regressors with numerical splits

cuML RF classifiers are not supported.

[wphicks]

Locally, I'm getting RF tests outside of the set tolerance:

________________________________________ test_cuml_rf_classifier ________________________________________

    def test_cuml_rf_classifier():
        X, y = fetch_california_housing(return_X_y=True)
        X, y = X.astype(np.float32), y.astype(np.float32)
        cuml_model = curfr(max_features=1.0, max_samples=0.1, n_bins=128,
                           min_samples_leaf=2, random_state=123,
                           n_streams=1, n_estimators=10, max_leaves=-1,
                           max_depth=16, accuracy_metric="mse")
        cuml_model.fit(X, y)
        pred = cuml_model.predict(X)
        tl_model = cuml_model.convert_to_treelite_model()
    
        explainer = TreeExplainer(model=tl_model)
        out = explainer.shap_values(X)
>       np.testing.assert_almost_equal(np.sum(out, axis=1), pred, decimal=3)
E       AssertionError: 
E       Arrays are not almost equal to 3 decimals
E       
E       Mismatched elements: 8457 / 20640 (41%)
E       Max absolute difference: 1.1803854
E       Max relative difference: 0.36403635
E        x: array([4.086, 3.846, 4.045, ..., 0.858, 0.856, 1.061], dtype=float32)
E        y: array([4.055, 3.946, 4.045, ..., 0.866, 0.856, 1.061], dtype=float32)

[wphicks]

Should we put this in the experimental namespace for 21.12?

[wphicks]

The logic of this function seems generally correct, but it's also a bit hard to follow. Could we break it up a bit or consider using algorithms directly on the underlying containers where feasible rather than trying to keep track of all the separate indexes?

[hcho3]

I fixed the failing unit test. Marking this PR as non-draft, since it's functionally complete. I'll now address stylistic concerns.

[wphicks]

I think it would be better to avoid the dynamic_cast here (and the general complexity of the inner implementation classes for different types) by using a single struct with a std::variant member variable, but let's just make note of that and save it for a follow-on.

[codecov-commenter]

Codecov Report

❗ No coverage uploaded for pull request base (branch-21.12@34f7929). Click here to learn what that means.
The diff coverage is n/a.

@@               Coverage Diff               @@
##             branch-21.12    #4351   +/-   ##
===============================================
  Coverage                ?   85.65%           
===============================================
  Files                   ?      236           
  Lines                   ?    19179           
  Branches                ?        0           
===============================================
  Hits                    ?    16427           
  Misses                  ?     2752           
  Partials                ?        0           

Flag	Coverage Δ
dask	46.17% <0.00%> (?)
non-dask	78.49% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 34f7929...56d62d3. Read the comment docs.

[wphicks]

@gpucibot merge