Allow use of $date (EJSON wrapper) for API Table timestamp values (similar to Collections)

[tatu-at-datastax]

Currently (v1.0.18) API Table columns of type timestamp accept and produce JSON String values (using ISO-8601 encoding). This is different from Collections where EJSON-wrapping with numeric timestamp like:

{ "$date" : 123005946 }

is accepted and produced.

Questions: should we use or allow EJSON-wrapped values for API Tables as well? There are couple of questions to decide:

1. Should we accept both notations ("plain" String and EJsonWrapper) or just one -- and if so, which one?
2. If both are accepted, which one should be produced (returned with "findXxx" commands (if only one accepted that'd be one produced too)
3. If EJSON-wrapped value accepted, should it accept numeric Timestamp (like Collections), or ISO-8601 String (like current API Table).

These decisions should be based on what makes most sense from client perspective: since API Tables not yet externally released we can still change the notation/representation to use.

EDIT:

Answers: we will work to maximize interoperability with Collections.

1. Should accept BOTH, for interoperability with Collections (so yes accept ALSO EJSON-wrapped values)
2. Return "plain" ISO-8601 String representation (same as now, no change)
3. Accept Timestamp (seconds since Epoch, Java long), same as with Collections, for interoperability.

[vkarpov15]

Allowing { $date: 123456 } would make things a little easier for stargate-mongoose, because that's how stargate-mongoose serializes dates currently: https://github.com/stargate/stargate-mongoose/blob/1713dc9206c5891742aa1fdbf71ea7420a81d003/src/client/serialize.ts#L59-L62.

Someday stargate-mongoose may need a "am I talking to a table or a collection?" option, but it would be great to avoid that if possible. Supporting { $date } would mean we can do dates without knowing table or collection.

[tatu-at-datastax]

@vkarpov15 That's the idea indeed! Thank you for confirming that the change makes sense. I hope to tackle this issue soon.