Infer count() aggregation is not null

[findepi]

count([DISTINCT [expr]]) aggregate function never returns null. Infer non-nullness of such aggregate expression. This allows elimination of the HAVING filter for a query such as

SELECT ... count(*) AS c
FROM ...
GROUP BY ...
HAVING c IS NOT NULL

[findepi]

Added unit and integration tests. Should be ready to review.

[findepi]

@alamb PTAL

[alamb]

Thank you very much @findepi -- for both this PR and your other recent contributions. I will indeed review this PR, though I may not get to it until tomorrow or Friday

[jonahgao]

I think there might be a simpler way to achieve this.

We can declare the count aggregation expr as non-nullable like this, and then the simplify_expressions rule and the eliminate_filter rule will handle subsequent processing.

datafusion/datafusion/optimizer/src/simplify_expressions/expr_simplifier.rs

Lines 1450 to 1454 in 6e63748

	Expr::IsNotNull(expr) | Expr::IsNotUnknown(expr)
	if !info.nullable(&expr)? =>
	{
	Transformed::yes(lit(true))
	}

[findepi]

@jonahgao thanks!
I think we may later choose to add a similar optimizer to the one that was proposed here for the sake of filter expressions. Let's not add one if not needed today.

[findepi]

To address this TODO we could extend the pattern here

datafusion/datafusion/expr/src/aggregate_function.rs

Lines 84 to 88 in 4bc3228

	pub fn return_type(
	&self,
	input_expr_types: &[DataType],
	input_expr_nullable: &[bool],
	) -> Result<DataType> {

ie now we have return_type(input_types, nullability) -> return_type
we could have return_type(input_types, nullability) -> (return_type, nullability)

this is an API for builtin functions, we would need similar API for UDAFs

datafusion/datafusion/expr/src/udaf.rs

Line 330 in 5f02c8a

fn return_type(&self, arg_types: &[DataType]) -> Result<DataType>;

Obviously, this would be a breaking change: both method signature and return type would change.
We can avoid the breaking change by making nullability a separate method, but it would be good to first determine the ideal end-state, and only then think how to get there.

[findepi]

copied into #11274

[jonahgao]

Looks good to me. Thanks @findepi . Other questions could be resolved through subsequent PRs.

[findepi]

thanks @jonahgao for your review! updated.