master load meta table

大开脑洞的想法：
**获得的好处：**
1. 彻底解决meta和master内存不一致问题
2. load/unload/split...不需要单独为meta弄一个if分支
3. 对meta的访问不会被其它表影响
4. 可以做针对meta的专门优化，例如全内存存储、利于查询的内存结构

**带来的问题：**
1. 写扩展性：写是由master发起的，如果写meta成为瓶颈，那master的处理一定先成为瓶颈。在解决这个问题之前，master需要先拆分。
2. 读扩展性：master可以指定一些ts成为meta代理，只提供读服务。
3. master不能挂：master本来也不能挂（挂了没人管load），master本来也可以挂（master有热备）。
4. 架构不够牛逼啊：如人饮水冷暖自知，牛逼不能当饭吃，如果不是遇到各种问题，我也不会有这想法了。

抛开改动成本这些问题，假如tera是从头开始，你会支持这种设计吗？请写下你的看法。

The issue does not name any files, tests, or entry points. Start by reviewing the existing master/meta architecture and the load, unload, and split paths; done would require an agreed design for loading the meta table through master, including how consistency and read/write scaling should work.

Written by the indexing model from the issue text.