[SPARK-28483][FOLLOW-UP] Fix flaky test in BarrierTaskContextSuite

[WeichenXu123]

What changes were proposed in this pull request?

I fix the test "barrier task killed" which is flaky:

• Split interrupt/no interrupt test into separate sparkContext. Prevent them to influence each other.
• only check exception on partiton-0. partition-1 is hang on sleep which may throw other exception.

Why are the changes needed?

Make test robust.

Does this PR introduce any user-facing change?

No.

How was this patch tested?

N/A

[WeichenXu123]

Jenkins, retest this please.

[SparkQA]

Test build #110634 has finished for PR 25799 at commit 9dbdcb8.

• This patch fails Spark unit tests.
• This patch merges cleanly.
• This patch adds no public classes.

[SparkQA]

Test build #4869 has finished for PR 25799 at commit 9dbdcb8.

• This patch fails Spark unit tests.
• This patch does not merge cleanly.
• This patch adds no public classes.

[HyukjinKwon]

retest this please

[SparkQA]

Test build #110703 has finished for PR 25799 at commit 9dbdcb8.

• This patch fails Spark unit tests.
• This patch merges cleanly.
• This patch adds no public classes.

[SparkQA]

Test build #110732 has finished for PR 25799 at commit c8dcf42.

• This patch fails build dependency tests.
• This patch merges cleanly.
• This patch adds no public classes.

[WeichenXu123]

retest this please

[SparkQA]

Test build #110739 has finished for PR 25799 at commit c8dcf42.

• This patch fails due to an unknown error code, -9.
• This patch merges cleanly.
• This patch adds no public classes.

[dongjoon-hyun]

Retest this please.

[SparkQA]

Test build #110750 has finished for PR 25799 at commit c8dcf42.

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

[HyukjinKwon]

@WeichenXu123, while this PR seems fine, please make sure you have a sign-off or an approval from another committer, which is a standard approach. At least, you can wait for some positive comments. Or, please clarify the reason why you're merging it without any sign-off from other people.

In this way, you can a) avoid unexpected mistakes, and b) have another person who can take over your change, say, if you happen to leave this project; otherwise, no one can take over if most of changes are just merged without peer-review.

Although it is legitimate to merge as a committer as far as I know, we should better stick to this practice. Avoid to set a bad example.

[HyukjinKwon]

Also, please clarify which branch you merged (e.g., "Merged to master") to avoid the overhead for people to check commit history to see which branch it was merged.

[srowen]

Looks OK to me.
Yeah I'd say it's a judgment call, if it's a minor change and you feel sure about it and nobody has weighed in for a day or two, it's not unreasonable to proceed. If in doubt I'd try pinging someone for a second look.

[srowen]

For the record looks like this was merged to master