feat: added error codes for supervisor RPC errors

[07Vaishnavi-Singh]

Closes - #660

Changes

• Added an "Errors" section to the Supervisor spec document with two subsections:
  • Standard JSON-RPC Error Codes (-32700 to -32006)
  • Protocol-Specific Error Codes (-32100 to -32119)
• Mapped Go error types from the codebase to specific error codes
• Used consistent error code grouping with shared prefixes
• Followed standard JSON-RPC error formatting and descriptions

[07Vaishnavi-Singh]

hey @emhane, can you provide a review....will fix it according to the suggestions. ty!

[emhane]

great start! first pass, will give this another pass in a bit. I like that you make the distinction between e.g. unknown chain and errors more specifically related to data availability by using the 3210 and 3211 prefixes respectively

[emhane]

thought again about how to do the codes, let's do this:

• we add an extra digit, so we are guaranteed not to conflict with l1 error codes https://ethereum-json-rpc.com/errors, we get 6 digits
• we use gRPC status codes to group errors https://grpc.io/docs/guides/status-codes/. this helps users guess the error type of unknown errors and gives nice system to follow.

the 6 digit error code is made up as follows

• first 2 digits reserved for 32XXXX meaning server error
• following digit pair reserved for gRPC error category (1-16)
  e.g. 320600 refers to the first server error of category ALREADY_EXISTS = 6.
  we use 06 so we can make the distinction between status code CANCELLED = 1, 3201XX, and ABORTED = 10, 3210XX.
• last digit pair is reserved for indexing errors of same gRPC code on the same server. so, 320601 is the second error of category ALREADY_EXISTS on the server.

[07Vaishnavi-Singh]

Hey @emhane, I have adjusted the error codes according to the 6-digit standard, and also made the small refactoring nits asked. lmk if something still needs to be done. ty!

[emhane]

super nice! some nitpicks remaining

[emhane]

awesome. thanks a lot !

[07Vaishnavi-Singh]

hey @emhane , can you provide some TG would be helpful while implementing these error codes in reth

[emhane]

hey @emhane , can you provide some TG would be helpful while implementing these error codes in reth

sure, when this pr is merged is a good time to start impl in reth

[tynes]

flagging @alfonso-op on this. we will want to make sure that the error codes make sense for proxyd and that the user story of a transaction being sent that includes an invalid access list is dropped returns an error code that is well defined and included in common libraries like viem