[Improve][SDK] Improvements to TypeConverter field types and CompareValue in OperatorTools

[Zkplo]

Description

• parent issue [Umbrella] Tencent Rhino-bird: Expand InLong Transform functions #10796

Data:

numeric1|numeric2|numeric3|numeric4
3.14159265358979323846|4|6|8

SQL Statement:

select if(numeric2 = 4,1,0) from source;

Background:
When parsing 'numeric2=4', the following function will be entered:

org.apache.inlong.sdk.transform.process.operator.OperatorTools#compareValue()
public static int compareValue(Comparable left, Comparable right) {
	if (left == null) {
		return right == null ? 0 : -1;
	}
	if (right == null) {
		return 1;
	}
	/*
		When one of the left and right is a string, the other is assumed to be BigDecimal, but there are other types present during the parsing process. 
		For example, here JSQLParser parses the 4 in the expression as a Long type, while numeric2 is parsed by the SDK as a string "4". In "ObjectUtils.compare()", an error occurs due to inconsistent types on both sides.
	*/
	if (left instanceof String) {
		if (right instanceof String) {
			return ObjectUtils.compare(left, right);
		} else {
			BigDecimal leftValue = parseBigDecimal(left);
			return ObjectUtils.compare(leftValue, right);
		}
	} else {
		if (right instanceof String) {
			BigDecimal rightValue = parseBigDecimal(right);
			return ObjectUtils.compare(left, rightValue);
		} else {
			return ObjectUtils.compare(left, right);
		}
	}
}

Questions:

1. The Transform reserved a field type interface, but it was not used in subsequent development.
2. The compareValue method in OperatorTools did not take into account in detail the types involved in comparing the two instances.

InLong Component

InLong SDK

Are you willing to submit PR?

• Yes, I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct