refactor(artifact): using grpc error code

[Yougigun]

Because

using more semantic grpc code to map into http code

This commit

implement corresponding error so that the error interceptor can work

[linear]

INS-4792 Artifact optimize http code using grpc code

[jvallesm]

Hi @Yougigun I saw this PR once merged but I would have liked to add the following comment. It is not a blocker, just for awareness.

I can't find the conversation (I think it happened on a PR like 1 month ago) but I proposed to @donch1989 using a single package to communicate errors through packages. These errors would be a bit more generic (not found, resource exists, invalid argument...) and the package generating the error would be responsible of wrapping a given error into the domain one. This has several advantages:

• In the interceptor we'd reduce a lot the amount of errors and packages we manage. Right now when we add a feature that returns a given error, we need to remember to handle it in the interceptor.
• We can implement a retry policy handler for Temporal workflows or other type of event handler without copying all the errors that middleware already handles.
• Ideally we could define these errors in service, which acts as the domain layer. Sadly, the current dependency injections would cause dependency cycles. However, using a package to communicate errors will sanitize some of this dependencies (in the cases where the package calls a dependency through an interface but it still needs to import the implementation package to handle the error).

[Yougigun]

I like the idea of using a single error package. The reason I have a custom error is also to try and solve the dependency cycle. I will try to use only a single error package in the interceptor over the following iteration.

[jvallesm]

The reason I have a custom error is also to try and solve the dependency cycle

Yes I'm feeling that pain, too. One problem we have is that, even if we communicate through interfaces, many times we define them in the implem package instead of in the caller / in a separate package, which produces the same dependencies as if we were using a struct directly.