tiflash path can be seen as a kind of logical-prop to guide upper operator to generate mpp task or not

## Enhancement


when we are planning mpp join, we use allowMPP switch and p.canPushToCop(tiflash) to judge whether we can generate shuffleJoin or boardCast join directly, and if it is and hint is preferred, we just return them directly, while since p.canPushToCop(tiflash) may not that correct as we expected. We should postpone this kind of hint handling into attachment phase.

That means we want to lift the canPushToCop check here, while for most of the case, always generating a mpp join here and fail in the child building like ds can't find any tiflash path is quite a common and simple case which can be avoided by maintain a kind of logical property bottom-up to simply guide upper join to avoid generate mpp join if any side of its child lost the tiflash-path-prop maintained.