[BUG] Literals of nested type are ignored when estimating the output size in PreProjectSplitIterator

[firestarman]

Describe the bug
When running the following toy query, the estimated output size (167.688 KB) returned by "PreProjectSplitIterator.calcMinOutputSize" is quite less than the actual size (1269.768 KB) after the project .

spark.range(1024*10).selectExpr("cast(id as long)").createOrReplaceTempView("tt")
sql("select
       distinct(id),
       array(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23) as a24,
       array(1,2,3) as a3 from tt"
).collect

Projection list:

  ==>Expr 0: GpuBoundReference input[0, bigint, false](id#15)
  ==>Expr 1: GpuAlias [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23] AS [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23]#24
     Children:
    ==>Expr 0: GpuLiteral [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23]
  ==>Expr 2: GpuAlias [1,2,3] AS [1,2,3]#25
     Children:
    ==>Expr 0: GpuLiteral [1,2,3]

According to the projection list in the above query, the output batch size is about 12 times bigger than the input batch in theory without offset and validity buffers, and we saw a batch of ~4.4G size in some custom queries on T4.

Look at the code here, GPU literals of nested type (array of integer) are not included in the estimated output size. Then the output size is still small enough to make no real splitting happen (but splitting is expected), producing a very big batch in the production env.