fix(extensions)!: correct return type for subtract:date_iday operation

[nielspardon]

BREAKING CHANGE: changes the return type of the subtract:date_iday function from date to precision_timestamp

Fix the return type of the subtract function when subtracting an interval_day from a date. Since interval_day is an interval of days to subseconds the operation should return a precision_timestamp type, not a date type.

This corrects the function signature in functions_datetime.yaml where date + interval_day was incorrectly specified to return date instead of precision_timestamp.

This is similar to #1007 and was originally reported in #576.

This also fixes the subtract:ts_iday test cases to use a precision type parameter for iday.

---

This change is 

[yongchul]

Wait what? The existing change looks correct to my eyes.

[nielspardon]

If you subtract 1 day, 2 hours, 3 seconds, 4 microseconds from a date what do you expect to be returned? Certainly not a full date anymore but a timestamp and given that interval_day has a precision for subseconds it would be a precision timestamp of the same precision as interval_day.

[yongchul]

Thank you for pointing that out but that opens even more questions. If that is the case, we should update all other things? For instance, timestamp and timestamp_tz are at microsecond precision. So if you do math with interval_day<P>, it should be the higher precision of max(6,P)?

or,

if (P <= 6) then (timestamp) else (precision_timestamp<P>) 

[nielspardon]

So I already have this PR open for removing the old timestamp, timestamp_tz and time types which should simplify such scenarios somewhat. We can check if the remaining precision_timestamp, precision_timestamp_tz, precision_time functions handle the precision correctly.

[nielspardon]

I merged #994 and rebased this PR on latest main.

[nielspardon]

We do indeed have the situation in function signatures where datetime return type precision is derived from directly from the argument precision where e.g. for add:pts_iday both arguments need to have the same precision P:

substrait/extensions/functions_datetime.yaml

Lines 206 to 211 in 87d73b6

	- args:
	- name: x
	value: precision_timestamp<P>
	- name: y
	value: interval_day<P>
	return: precision_timestamp<P>

We could (in a follow-up) change this for more flexibility to:

      - args:
          - name: x
            value: precision_timestamp<P1>
          - name: y
            value: interval_day<P2>
        return: |
          P = max(P1, P2)
          precision_timestamp<P>

[nielspardon]

created a new issue for looking into the return type precision: #1033

[yongchul]

Sounds good. Thank you for creating the follow up issue!

[nielspardon]

FYI: found another issue today raising the exact same issue #926

Looks like @vbarua is of the opinion that one should explicitly cast the argument precision to the same precision before the function call in the older issue.

[yongchul]

+1 but I have no idea whether this will cause any problem to anyone or not...

[benbellick]

Since this makes it consistent with add now, LGTM!