[DISCUSS] Gremlin Server Error Return Improvements

[Stephen Mallette <sp...@gmail.com>]

Gremlin Server errors reported to the client aren't always telling. It
typically returns the error message from an Exception (and tries to pull
the "best" message by unwrapping the "cause" if present). That approach
works for most cases but I've had the disprivilege of being on the
receiving end of some of those errors in debugging when only the client
side message was present and it's a mess trying to rectify that simple
message with a server log somewhere. Another annoyance is when you get an
empty exception message on the server - which in turn translates to an
empty error message on the client.

I'm planning several changes which I think will be good:

1. Include "exceptions" and "stackTrace" in status attributes where
"exceptions" will be a list representing the exception hierarchy and
"stackTrace" will obviously be the remote stack trace
encountered. These will be added to both the Gremlin Server protocol and
the HTTP protocol
2. Deprecate the "Exception-Class" in the HTTP protocol which is now better
served with "exceptions". "Exception-Class" doesn't match our naming scheme
and only yields the top level exception which isn't always useful to
solving the problem.
3. Alter the ResponseException in the java driver to expose the two new
fields when a remote exception is raised. Not sure if we want to beef up
the python driver's error handling - it looks like right now it just
concats the status and message into a string output. Perhaps that's a
separate issue - maybe Dave can offer some thoughts since he's most
familiar with that code.

Could this be handled any differently or can we do anything else to help
make debugging server problems a little easier?