Properly support dd.Index in setitem

[TomAugspurger]

We don't want to align these. It has the same semantics as setting a dask array: we validate that the number of blocks match the number of partitions, and assume that the size of each block / partition matches.

This is a bit light on tests at the moment for invalid input (since we're re-using the dask.array implementation).

Closes #5702

cc @AlbertDeFusco

[TomAugspurger]

I updated assert_eq a bit. We're generating key-names that are slightly too long for assert_sane_keynames (101, and the cutoff is 102).

I updated assert_eq to be able to control what it considers too long. Alternatively, I could debug why we're making longer key names.

[mrocklin]

Alternatively, I could debug why we're making longer key names.

This sounds like a good idea to me if you have the time. No expectations though if the cost/benefit ratio isn't high enough.

[jrbourbeau]

Just a couple of nitpicks

[TomAugspurger]

This sounds like a good idea to me if you have the time. No expectations though if the cost/benefit ratio isn't high enough.

The short version is we have task names like {new-key}-{new-token}-index-{old-token}

from_pandas-8595dbb3832b7f73fae91c38aae7c616-index-da2e17dacb52404ea6cc043a671e8659

but I haven't figured out why yet, or what the old names were.

[mrocklin]

We should probably just include the old token (or the old dataframe) within the tokenize call when we generate the new token. Having multiple tokens lying around is probably a bad idea.