Okay, I've updated the branch to address your changes, with roughly one commit per comment to make it easier to follow. Some responses:
It's not entirely this patch fault but I don't understand why we need FunctionName.equalsNativeFunction
It's just to assume the system keyspace if a keyspace isn't set on the function. I've modified the function to make that more correct and a little clearer. Let me know if that makes sense to you.
If we made fromJSONObject return a Term, we'd avoid serializing collection to re-deserialize them right away.
I too would like to avoid the unnecessary serializations and deserializations. We have this problem in other parts of the code as well (IN value lists, multi-column relations, and collections in column conditions, iirc). However, I'm not clear on what you're suggesting. Can you elaborate?
FromJsonFct should probably use the new ExecutionException
I'm not sure about this. Errors in FromJsonFct are type errors of a sort (at least if you consider JSON's native type formatting) or incorrect CQL literals (which also result in an IRE). I think sticking with an IRE for type errors with native functions would be more consistent from a user's point of view. Plus, the purpose of ExecutionException is pretty clear right now: it's for errors that occur while executing a user-defined function. We would lose that if we use it here.
For INSERT JSON, I think having a ParsedInsertJson separate from ParsedInsert makes things a bit cleaner. [...] How do you feel about it?
I definitely agree that the separate Insert classes are an improvement. The Json Term refactoring is less of a win, because it still has some odd parts (classes that are both Raw and Terminal), but the old version had odd parts too. I'm fine with the new setup, so I made those changes with a few things renamed for clarity (e.g. SimplePrepared -> PreparedLiteral).
Any particular reason for having DecimalType and IntegerType quote their values?
Well, I had some concerns around loss of precision and overflows if the client-side JSON decoder attempted to store them as, say, Java doubles and longs. However, I think it would be reasonable to say that the client should ensure their JSON decoder handles these issues. So for now, I've switched them to non-string representations. Let me know if you thing the client-side decoding issues warrant keeping them as strings.
Out of curiosity, was there a profound reason to make Term.Terminal take the protocol version only?
This was part of what I was attempting to address with the CollectionSerializer.Format code (now reverted). Some parts of the code need to specify a format/protocol version without any QueryOptions present (or it doesn't make sense to use QueryOptions). It's a bit weird to pass around a protocol version when we're not actually dealing with the native protocol, which is why I looked at switching to a format enum.
I understood why we were using QueryOptions to begin with, but this seemed like the least invasive change.