perf: cache row if it is a transformed row

[jasonk000]

Reduce the number of times a timestamp is parsed and read if the row is a transformed row.

During ingestion the parsing and appending functionality requires repeated access to the timestamp information from the row. In the case of a TransformedInputRow, this could be an expensive step:

{
  "type": "expression",
  "name": "__time",
  "expression": "(point_seconds * 1000.0) + (point_nanos / 1000000.0)"
},

By caching this row, a significant reduction in CPU time can be achieved, in this example from 14% to 4% of CPU involved in reading Timestamps, a 10% reduction. This change converts the processing from lazy load of timestamp during Transform to an eager transform, and then keeps the result.

Before:

After:

This PR has:

• been self-reviewed.
  • N/A using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• added documentation for new or modified features or behaviors.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• N/A added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• N/A added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• N/A added integration tests.
• been tested in a test Druid cluster.

[FrankChen021]

Why not cache the DateTime object instead of the long? By doing that we can save many temp objects creation.

[jasonk000]

Sure, fixed in f444ad2.

It's not material to performance, but it also shouldn't hurt.

[suneet-s]

Thanks for the optimization @jasonk000 ! The test failure appears unrelated.