[Cluster-refactor] About refine classes name

> Background: we're working together with @jixuan1989 to refactor cluster module. The dev branch is `cluster-`

## Why

When I first looked at the codes of IoTDB, I lost in the kinds of `***Services`, I want to make it clear to let more dev can hand on codes a bit easier by the opportunity.

After reviewing the code, I think the request process flow could be divided into 3 layers as show in the image. The structure is clear but not classes name. So, I think we can refine the class names in **Transport layer** and **RPC interface layer** to make codes clearer.


## Suggestions

I don't align the suggestion changes with the class names in the server module because I don't think sever module is clear enough according to my understanding. And let's go through these layers.

### Cluster Instance
`ClusterIoTDB` is the server instance which control the sub servers lifecycle.

### Transport Layer
I call this layer as transport layer because the instances in the layer take charge of setup port listening, setup TCP work threads, establish connection, hand over requests... via thrift APIs.

Right now the class in this layer are called `***Service` which I don't think is clear. An idea is rename the classes as `***SubServer`.

### RPC interface Layer

The classes in this layer are the implementation of thrift RPC interfaces which handle the RPC call from thrift client.

Right now the class in this layer are called `***Service`. If we can change the classes name in the `transport port` layer, I think `***Service` here is acceptable. A suggestion is `***RPCHandler` which is better than `***Service` in current implementation IMO. `***Service` could be used to hide the concrete RPC framework like thrift but right now we don't have that layer.

### Executor Layer

The classes in the layer encapsulate the concrete execution logic. Won' analysis here.

Finally, welcome join the discussion and every idea is import for us.

Start by reviewing the cluster module on the `cluster-` dev branch and mapping the classes in the Transport and RPC interface layers. Resolve whether transport classes should use `***SubServer` and RPC implementations should use `***Service` or `***RPCHandler`; done means the naming is agreed and applied consistently across the refactor.

Written by the indexing model from the issue text.