Fix context error in grpc

[chenquan]

目的:

将context返回的错误,转换成grpc可以识别的错误

该PR合并后,以下代码将永远不会被执行,应该移除它
https://github.com/tal-tech/go-zero/blob/d0f9e5702289b32b5d289ad2418d8b91b0807c6e/zrpc/internal/codes/accept.go#L24-L25

linked：#792

[kevwan]

AddBreakerErrors 我觉得不需要吧？什么情况下会用到？

[chenquan]

AddBreakerErrors 我觉得不需要吧？什么情况下会用到？

我理解的是,可能存在并非当前调用微服务实例本身不可用,而是该微服务实例中存在调用其他的系统的错误(例如网络错误等), 针对类似场景我觉得需要自定义熔断错误

[kevwan]

那也是这个服务依赖的服务有问题而导致该服务不可用，也应该熔断。

另外，对于未知的情况不做过多预判，如非必要，勿增实体。

[chenquan]

那也是这个服务依赖的服务有问题而导致该服务不可用，也应该熔断。

另外，对于未知的情况不做过多预判，如非必要，勿增实体。

如非必要，勿增实体 赞!!!

那我将移除AddBreakerErrors部分代码

[chenquan]

那也是这个服务依赖的服务有问题而导致该服务不可用，也应该熔断。

另外，对于未知的情况不做过多预判，如非必要，勿增实体。

另外顺便请教一下,如果这个服务A依赖的服务B是外部服务,服务B不属于go-zero体系,可能是基于其他方式调用(如restful)而在调用该服务B的时候,服务A作为客户端是否也应该自行做熔断?(假设服务B作为服务端已经做了熔断)

[kevwan]

那也是这个服务依赖的服务有问题而导致该服务不可用，也应该熔断。
另外，对于未知的情况不做过多预判，如非必要，勿增实体。

另外顺便请教一下,如果这个服务A依赖的服务B是外部服务,服务B不属于go-zero体系,可能是基于其他方式调用(如restful)而在调用该服务B的时候,服务A作为客户端是否也应该自行做熔断?(假设服务B作为服务端已经做了熔断)

完全可以的，core/breaker可以直接用来处理外部请求