The last of the getTimeFieldSpec calls

[npawar]

#2756
Removing the last of the getTimeFieldSpec calls.

1. SegmentGeneratorConfig now uses the new getSpecForTimeColumn() call, which returns a DateTimeFieldSpec. Time column is expected in table config if it is to be considered when creating segment. (this also sets the stage for allowing a DateTimeFieldSpec to be a primary time column)
2. Removing TimeFieldSpec special handling from RealtimeSegmentConverter.getUpdatedSchema. There is no need to remove the incoming time spec. Neither the recordReader nor the dataSource require the updated schema. Plus, the record transformer is a pass through.
3. Removing special casing for TimeFieldSpec in Schema.isBackwardCompatible() method. The for loop for all specs includes time

[Jackie-Jiang]

Not related to this PR, but inside the Schema can we do the TimeFieldSpec to DateTimeFieldSpec conversion on the setter side instead of the getter side?
The problem of conversion on the getter side is that the schema still stores the deprecated TimeFieldSpec, and getFieldSpecMap() and getFieldSpecFor() will still return the TimeFieldSpec instead of DateTimeFieldSpec. This can easily cause bugs inside the code.

[Jackie-Jiang]

Do we still want this support? (Realtime table without time column)

[npawar]

realtime table without time will never happen right?
Also after changing the getUpdatedSchema method, this test becomes irrelevant

[Jackie-Jiang]

I think @fx19880617 added that support. Any opinion on this?

[npawar]

Not related to this PR, but inside the Schema can we do the TimeFieldSpec to DateTimeFieldSpec conversion on the setter side instead of the getter side?
The problem of conversion on the getter side is that the schema still stores the deprecated TimeFieldSpec, and getFieldSpecMap() and getFieldSpecFor() will still return the TimeFieldSpec instead of DateTimeFieldSpec. This can easily cause bugs inside the code.

That was exactly the initial plan - to modify the setter to save it as a DateTimeFieldspec. But now we changed the plan. We are not going to do any changes to ser/deser. Reason mainly being external integrations (presto, superset etc) which still need TimeFieldSpec, and also upgrades. I've updated the design doc: https://docs.google.com/document/d/1SU1jCjfsIDSA960fD5YWQbD72p8UdGF0c7CroFNt9Ho/edit#heading=h.6gaudq1t6ys8 (Step C and also put the previous approach in Discarded section)

New plan is to make sure Pinot can treat TIME or DATE_TIME either of them as the primary time column.