Gracefully handle unsupported data types , e.g. serialize a PyObject into a string and display as such

[jmao-denver]

during my attempt to solve #275 - allow direct property access of a Python object in query strings, as an incremental step, I decided to return the property as a generic PyObject instead of the actual string value (or numbers), the query ran through but the table column failed to display. No exceptions in the server log. In the browser (Chrome), I got this in the console output.

dh-internal.js:1 Uncaught Error: java.lang.IllegalStateException: Can't decode column of type io.deephaven.db.tables.remote.preview.DisplayWrapper
    at IllegalStateException_0.createError (dh-core.js:1294)
    at IllegalStateException_0.initializeBackingError (dh-core.js:1305)
    at IllegalStateException_0.Throwable_0 (dh-core.js:1259)
    at IllegalStateException_0.Exception_1 (dh-core.js:1329)
    at IllegalStateException_0.RuntimeException_1 (dh-core.js:1342)
    at new IllegalStateException_0 (dh-core.js:26447)
    at Object.readArrowBuffer (dh-core.js:11495)
    at Object.createSnapshot (dh-core.js:11275)
    at Object.$lambda$36 (dh-core.js:9822)
    at Function.apply_40 (dh-core.js:10765)
    at lambda (dh-core.js:147)
    at dh-internal.js:10
    at Array.forEach (<anonymous>)
    at onMessage (dh-internal.js:10)
    at Array.<anonymous> (dh-internal.js:1)
    at e (dh-internal.js:1)
    at dh-internal.js:1

Spoke with Colin and he stated that both the server and the client aren't equipped to handle such cases yet. But since Enterprise can do that, it is something we will want in OSS.

[jmao-denver]

Maybe we can infer the actual data type to better support data generated from Python object at runtime.

[nbauernfeind]

I will look into this right now; if the server advertises this as a string (and converts to string on behalf of the subscriber) then this should "just work". It should be low hanging fruit to fix.

[niloc132]

@jmao-denver Any type inference work would be at the time of parsing the expression, so we could define the column's type in the table definition, probably out of scope here.

@nbauernfeind That would be my vote, that when the client doesn't opt-in to java OOS data, we send a string value instead, and mark the arrow/barrage schema node as "utf8", but leave the DH column type as the real underlying java type, whatever that might be. Client isn't smart enough at this time to decode that correctly, but as part of the other subscription improvements I have planned, it will figure that out (see #188).