Split RPC Callbacks into per feature

Currently most neutron plugins use mixin-style callback class like:

plugins/ml2/rpc.py
class RpcCallbacks(dhcp_rpc_base.DhcpRpcCallbackMixin,
                   sg_db_rpc.SecurityGroupServerRpcCallbackMixin,
                   type_tunnel.TunnelRpcCallbackMixin):

    RPC_API_VERSION = '1.1'

    def get_device_details(...)
    ....

oslo.messaging/openstack.common.rpc dispatcher compares a version of a received PRC method and RPC_API_VERSION in each callback class to determine the PRC method is supported.

An approach of using mixin-style callback class has the following disadvantages:
- If one RPC API (for example security group RPC) is bumped, RPC_API_VERSION of mixin callback classes needs to be bumped to match the new RPC version.
- RPC_API_VERSION of mixin callback class should be a max all versions of inheritance classes. In the above case, if DHCP RPC version is 1.0 and security group RPC is 1.1, RPC_API_VERSION should be 1.1.
- (Related to the previous) When we need to check all RPC versions when increment RPC version of a callback class of some classes to ensure the new version is not used so far. If DHCP RPC version is 1.0 and security group RPC version is 1.1, RPC_API_VERSION of mix-in class should be 1.1, and in this case the new version of DHCP RPC needs to be 1.2 because 1.1 is already used. Neutron has many plugins with various RPC supports, so it is hard to maintain RPC versions.

This blueprint proposes to split mixin RPC callback class into callbacks per feature to address the above problem: for example,

        callbacks = [ML2RPCCallbacks(self),
                     DhcpRpcCallback(),
                     L3RpcCallback(),
                     SecurityGroupServerRpcCallback()]
        self.dispatcher = q_rpc.PluginRpcDispatcher(callbacks)

In this approach, each RPC callback class has RPC_API_VERSION and each RPC (per feature) can evolve independently easily.
It affects all core/service plugins, but we can do this gradually without breaking any features.
I believe it makes the hurdle lower to implement new features/methods with RPC.