[SQL] Set outputPartitioning of BroadcastHashJoin correctly.

[yhuai]

I think we will not generate the plan triggering this bug at this moment. But, let me explain it...

Right now, we are using left.outputPartitioning as the outputPartitioning of a BroadcastHashJoin. We may have a wrong physical plan for cases like...

SELECT l.key, count(*)
FROM (SELECT key, count(*) as cnt
      FROM src
      GROUP BY key) l // This is buildPlan
JOIN r // This is the streamedPlan
ON (l.cnt = r.value)
GROUP BY l.key

Let's say we have a BroadcastHashJoin on l and r. For this case, we will pick l's outputPartitioning for the outputPartitioningof the BroadcastHashJoin on l and r. Also, because the last GROUP BY is using l.key as the key, we will not introduce an Exchange for this aggregation. However, r's outputPartitioning may not match the required distribution of the last GROUP BY and we fail to group data correctly.

JIRA is being reindexed. I will create a JIRA ticket once it is back online.

[SparkQA]

QA tests have started for PR 1735. This patch merges cleanly.
View progress: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/17754/consoleFull

[SparkQA]

QA results for PR 1735:
- This patch PASSES unit tests.
- This patch merges cleanly
- This patch adds no public classes

For more information see test ouptut:
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/17754/consoleFull

[marmbrus]

This is pretty minor and we can't even come up with a case where we plan incorrectly. I'm just going to merge this into master and 1.1 without a JIRA.

[marmbrus]

Thanks for fixing it!