简化 MetaCmd casToken 实现

[CDog34]

在使用时发现 casToken 存在问题：casToken 是私有结构体，意味着包外部的代码无法引用它，这一设计是有意为之的，因为理论上 casToken 只能由本包内生成且只在本包内使用，外部没有创建 casToken 的需求所以就没有把 casToken 结构体公开出去。然而在实际工程实践中，发现 casToken 经常会出现在函数形参中，参考业务中的一个方法

func SetItem(ctx context.Context, key, value string, casToken CasToken)(err error){ ... }

如果此时没有公开的 CasToken 结构体，那该方法就必须写成

func SetItem(ctx context.Context, key, value string, mr MetaResult)(err error){ 
    casToken := mr.CasToken
    ....
}

其中 mr 是上一次查询返回的 metaResult，这种写法传入了过多该函数职责之外的信息，不利于业务代码维护。

使用 interface 可以实现既保持 casToken 的收敛，又可被外部代码引用作为形参提升工程效率。
同时由于引入了 interface，其实参存在 nil 状态，于是便可区分为空和零值的情况，原先的 casToken 结构体也就不在必要，直接改为 int64 类型。

[taoso]

我在想是不是可以直接改成 int64。如果 cas 为 0 则表示不执行 cas 操作。关于之前提到的程序员想获取 cas token 却没有设置 c 标记的场景，让程序自行负责。本来也应该自己负责。现在为了这种边缘场景做出太多妥协没有必要。

[CDog34]

问题在于在「程序员想获取 cas token 却没有设置 c 标记的场景」时如果不区分零值和未设置，memcache 不会报错，而是直接当作非 CAS 操作设置成功，出现了问题却发现不了问题才是最大的问题。

「现在为了这种边缘场景做出太多妥协没有必要。」我不觉得这是妥协，我认为 cas 存在的意义就是防止意外更新，不管这个意外是并发造成的还是 bug 造成的。相反，我认为为了追求所谓简洁而牺牲鲁棒性才是妥协。

[taoso]

memcache 不会报错，而是直接当作非 CAS 操作设置成功，出现了问题却发现不了问题才是最大的问题

我可以举几个例子。一个是 root 下的 rm 工具，unix 并不会给用户提示确认，只要输出文件路径，就会删除。如果设置错路径，那是管理员的责任。

如果这个例子没有说服力，那可以参考 sql 的 delete 语句。如果开发者不指定 where 条件或者指定错了，那 db 也不会要求程序员确认。

综合以上，我认为没有必要为这种边缘场景做特殊的处理。如果程序员希望拿到 cas token，那他可以自己通过检查 cas 是否大于零来确认。如果他自己没设置 c 标记，也不自己二次检查，那就是他自己责任。

如果不能不处理这种情形，那也应该退回我最早的提议，用负数表示不存在的值。现在这种用 interface 再加上自定义 int64 类型的处理方式并没有什么优势。