fix(array): thread order parameter through to Array.__init__

[jhamman]

The goal here is to allow configuring the runtime memory order of arrays. We had all the pieces in place but we stopped short of passing order through to Array.__init__.

closes #2408

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/tutorial.rst
• Changes documented in docs/release.rst
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[d-v-b]

Suppose we change the key array.order to array_indexing.order in the config, this will happily return "C", when the correct behavior should be an error. Therefore I think we should define the default value higher up than this function, and this function should have a hard dependency on the schema of the config.

[jhamman]

I'm not sure I follow. What's the ask here?

[d-v-b]

I think the "default array order is C" logic should be defined higher up in the stack, instead of in this function. so the change would be to a) do that, and b) make this line order = config.get("array.order"), i.e. something that will error if we change the schema of the config.

[jhamman]

How much higher? We could require passing order into Array.create rather than allowing this to be a nullable field. Or we could do the config check there.

[d-v-b]

would it be possible to put the default in the config? I'm guessing we will have a lot of defaults (e.g., codecs), so would probably make sense to put them all in the same place

[d-v-b]

looks like the defaults are already in the config, in which case I think we can just remove any "default to C" behavior in _create_v2

[jhamman]

okay. I think the final state should be what you are after. Because the v2 array metadata requires order, we do have to check the config setting if no order was passed, but we no longer apply a default on top of that.

[d-v-b]

lgtm!