[2.4] Add xgboost histogram_based_v2

[YuanTingHsieh]

Description

• Add xgboost histogram_based_v2 codes
  Examples will come in another PR.

Conceptually, we use the following paradigm:

Detailed Implementation

The open-source Federated XGBoost (c++) uses gRPC as the communication protocol.
To use FLARE as the communicator, we simply route XGB’s gRPC messages through FLARE.
To do so, we change the server endpoint of each XGB client to a local gRPC server (LGS) within the FLARE client.
Similarly, there is a local GRPC Client (LGC) on the FL Server that interacts with the XGB Server.

As illustrated below:

The message path between the XGB Client and the XGB Server is as follows:

• The XGB client generates a gRPC message and sends it to the LGS in FLARE Client
• FLARE Client forwards the message to the FLARE Server. This is a reliable FLARE message.
• FLARE Server uses the LGC to send the message to the XGB Server.
• XGB Server sends the response back to the LGC in FLARE Server.
• FLARE Server sends the response back to the FLARE Client.
• FLARE Client sends the response back to the XGB Client via the LGS.

Code structure explanation

We introduce the following classes:

• AdaptorController: The workflow used on the FL server side to invoke server side adaptor
• AdaptorExecutor: The executor used on the FL client side to invoke client side adaptor
• XGBAdaptor: XGBAdaptors are used to integrate FLARE with XGBoost Target (Server or Client) in run time.
• XGBRunner: An XGBRunner implements XGB (server or client) processing logic. So XGBoost related federated API call will be here. How to invoke "xgb.train" is also in runner.
• GrpcServer, GrpcClient, proto folder: they exist to communicate with the open-source Federated XGBoost (c++) grpc server, so we take the protobuf definition from xgboost repo (https://github.com/dmlc/xgboost/blob/v2.0.3/plugin/federated/federated.proto)
• Sender: wraps around to send aux_message to the FL server side, will be enhanced later.

Types of changes

• Non-breaking change (fix or new feature that would not break existing functionality).
• Breaking change (fix or new feature that would cause existing functionality to change).
• New tests added to cover the changes.
• Quick tests passed locally by running ./runtest.sh.
• In-line docstrings updated.
• Documentation updated.

[chesterxgchen]

any unit tests ?

[yanchengnv]

Please remove all secure-related changes. Even if secure may be needed in the future (very unlikely), the way you did may not be the best way.

[yanchengnv]

LGTM

[YuanTingHsieh]

/build

[YuanTingHsieh]

Will add unit test / integration tests / example in the next PR