[SPARK-33933][SQL] Remove UT before we completely fix SPARK-33933

[zhongyu09]

What changes were proposed in this pull request?

Remove the UT "SPARK-33933: AQE broadcast should not timeout with slow map tasks" in AdaptiveQueryExecSuite

Why are the changes needed?

In #30998, we give a simple solution try to resolve SPARK-33933. However, the solution is not complete and the UT could not pass in some situations. For the stable of regression test, I suggest to remove the UT before we completely fix SPARK-33933.

Does this PR introduce any user-facing change?

No

How was this patch tested?

No

[zhongyu09]

@cloud-fan @viirya @dongjoon-hyun

[HyukjinKwon]

ok to test

[HyukjinKwon]

some situations

Mind elabourating what are the "some situations"?

[SparkQA]

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/38471/

[SparkQA]

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/38471/

[HyukjinKwon]

Looks like we need some investigations. Also it blocks RC preparation. I reverted this for now at 105ba6e. Let's make a PR again. I think that's the safe way.

cc @cloud-fan, @LuciferYang, @dongjoon-hyun FYI

[SparkQA]

Test build #133882 has finished for PR 31099 at commit e00e542.

• This patch passes all tests.
• This patch merges cleanly.
• This patch adds no public classes.

[zhongyu09]

some situations

Mind elabourating what are the "some situations"?

Because the submit of broadcast job and shuffle map job are in different thread,

1. for broadcast job, call doPrepare() in main thread, and then start the real materialization in "broadcast-exchange" thread pool: calling getByteArrayRdd().collect() to submit collect job
2. for shuffle map job, call ShuffleExchangeExec.mapOutputStatisticsFuture() which call sparkContext.submitMapStage() directly in main thread to submit map stage
   Removed reference to incubation in README.md. #1 is trigger in Removed reference to incubation in Spark user docs. #2, so in normal cases, the broadcast job will be submit first.
   However, we can not control how fast the two thread runs, so the "broadcast-exchange" thread could run a little bit slower than main thread, result in map stage submit first