refactor(zoe): Replace arrayToObj with objectMap

[gibson042]

Description

arrayToObj is an old function and has significant overlap with objectMap (the latter is basically Object.fromEntries(Object.entries(obj).map(([key, value]) => [key, mapFn(value, key)])), and the former is basically Object.fromEntries(zip(keys, values)) where values comes from manually mapping over original values).

This PR removes it in favor of more idiomatic code.

Security Considerations

n/a

Scaling Considerations

n/a

Documentation Considerations

Probably none; no new code is using the affected functions.

Testing Considerations

All remaining tests should continue to pass.

Upgrade Considerations

n/a; behavior is unaffected

[erights]

I'll wait until this is ready for review before doing a more careful read. But looks good to me so far. A welcome simplification!

[erights]

Please do fix all the imports of this. Thanks.

[gibson042]

There is a test failure in dapp-card-store integration caused by promise chains internal to deeplyFulfilled via E.when. It should be resolved by Agoric/dapp-card-store#73 .

[erights]

LGTM

[gibson042]

@erights: I added a new commit relating to yesterday's discussion: 726c44d

[kriskowal]

Looks mechanical to me.

[erights]

@erights: I added a new commit relating to yesterday's discussion: 726c44d

The disjointness of keywords will remain. So under that assumption, this indeed has no observable change. But it is more robust to possible future design changes as well as lack-of-enforcement errors.

Re "yesterday's discussion", I think that had to do with a restriction on having the "same" asset in give and want, for some def of "same" I cannot recall. In any case, @Chris-Hibbert is not finding that so my memory is likely confused. In any case, the problem we wanted to solve by lifting this (possibly non-existent) check would not be addressed by relaxing the disjoint keyword prohibition. They're independent.

In any case, still LGTM. Please proceed.

[Chris-Hibbert]

Most of this is a clean refactor. The code added in 726c44d looks like a semantic change. I'm going to add it to my list to be included in upgrade 16.