Fix map_blocks HLG layering

[TomAugspurger]

[x] closes #3599

This fixes an issue with the HighLevelGraph noted in
#3584, and exposed by a recent
change in Dask to do more HLG fusion.

cc @dcherian.

[dcherian]

Thanks for looking at this so quickly @TomAugspurger

So it was a graph construction issue.

Can you add some comments to make it clear why the graph needs to be constructed this way? You can also give yourself credit with a note in whats-new.rst

[TomAugspurger]

Hopefully the new comments make sense. I'm struggling a bit to explain things since I don't fully understand them myself :)

So it was a graph construction issue.

I think so. Dask doesn't actually validate arguments passed to HighLevelGraph. But I believe we assume that when all the values in dependencies are themselves keys of layers. We didn't have that before with things like

(Pdb) pp collections[0].dask.dependencies
{'all-84bc51ac43a9275b3662b0089710eab9': {'or_-64f95b81b2f8001b4c61f2023ac4c223'},
 ...
 'eq-abac622d95ce5055d3e7b7dea944ec37': {'lambda-e79de3edfa267f41111057d26471bce3-x',
                                         'ones-c4a83f4b990021618d55e0fa61a351d6'},
...
}

The 'lambda-e79de3edfa267f41111057d26471bce3-x' wasn't a layer of the graph. It was previously nested under the single new layer we were creating gname or lambda-e79de3edfa267f41111057d26471bce3 in this case.

[dcherian]

But I believe we assume that when all the values in dependencies are themselves keys of layers.

I came to the same conclusion when I looked at it but didn't know if this was by accident or design. The docs don't say anything.

anyway the fix looks good. Thanks for tackling this.

I'll merge tomorrow if there are no other comments.