Fix performance regression when hive SerDe doesn't prefer Writables

[pettyjamesm]

Introduced in #8206 GenericHiveRecordCursor was modified to avoid extra overhead when the SerDe provided a more efficient String handling implementation with Writables. However, when the SerDe does not provide such an implementation and instead already returned String instances directly, this change introduced an extra conversion from bytes to String just to be converted back to bytes.

This change alters the behavior of GenericHiveRecordCursor#parseString to respect the PrimitiveObjectInspector's preference for using writables.

== RELEASE NOTES ==
Hive Changes
* Fix a performance regression for String field handling in GenericHiveRecordCursor when the SerDe does not provide an efficient Writable implementation

[yingsu00]

Avoid DateTimeZone.getDefault() in GenericHiveRecordCursor hot path LGTM

I see too much Slice object creation in these code but they were like that from long time ago. Not to say we have to additionally improve it by avoid creating Slice's and memory allocations in this PR, but it's certainly something to explore in near future.

[pettyjamesm]

I see too much Slice object creation in these code but they were like that from long time ago. Not to say we have to additionally improve it by avoid creating Slice's and memory allocations in this PR, but it's certainly something to explore in near future.

Which copy are you seeing that we can avoid? The only avoidable one I see is this one https://github.com/prestodb/presto/pull/15163/files#diff-dc300db27cccd3a6d61eb547021170d6R432 to copy the contents if trimming the string down to character limits resulted in a smaller string, but without it you could have large buffers being retained by much smaller strings similar to String#substring problem that was changed in Java 7. Is there something else you see that we can easily address before merging?

[pettyjamesm]

@yingsu00 anything else we need to do here to be mergeable?

[yingsu00]

I see too much Slice object creation in these code but they were like that from long time ago. Not to say we have to additionally improve it by avoid creating Slice's and memory allocations in this PR, but it's certainly something to explore in near future.

Which copy are you seeing that we can avoid? The only avoidable one I see is this one https://github.com/prestodb/presto/pull/15163/files#diff-dc300db27cccd3a6d61eb547021170d6R432 to copy the contents if trimming the string down to character limits resulted in a smaller string, but without it you could have large buffers being retained by much smaller strings similar to String#substring problem that was changed in Java 7. Is there something else you see that we can easily address before merging?

I'm looking at removing the usage of Slice at all. The overhead creating Slices's is too high especially when the payload size is small. In our production workload we've seen it causing many GC issues. But it's not the scope of this PR. I'll accept it.

[yingsu00]

@mbasmanova Do you want to review for a second round of this PR?