Return Options as nullable values over PG Wire

[egormanga]

Description of Changes

Improves usability compared to regular DBs.

• Before:

   id | test         
  ----+--------------
    1 | {"some":"x"} 
    2 | {"none":{}}  

• After:

   id | test 
  ----+------
    1 | "x"  
    2 |      

Note:

The current implementation returns an empty string (2 bytes: "") on the wire. A correct one would return actual 0-byte NULLs, but this seemingly requires an elaborate refactoring of the current conversion implementation to support passing Option<AlgebraicValue> straight to the encoder, without converting it to a string first.

API and ABI breaking changes

Breaks the PG Wire protocol to move it closer to standard.

Expected complexity level and risk

3:

Will probably have to hear from pgwire's author if that's correct.

Testing

• Manual testing
• Unit tests

[joshua-spacetime]

@egormanga this seems reasonable to me, although I'd like to first design how we are going to handle/represent options and more generally sum types in Spacetime SQL before committing to this representation in pgwire.

[egormanga]

I believe, an Option should be just a nullable value, which fits nicely with outer join return schemas (e.g. #2892).

General sum types are a different beast. As long as we can deterministically parse them (e.g. u32 | str, but not u32 | i64), they can probably go untagged, like the usual SQL. If we do need the tags, then the current JSON-like repr seems to be the only possible option.