issues: 955029073

What happened:

With xarray 0.19.0, using open_mfdataset to read from a zarr store written with a previous version of xarray (with consolidated=True), I get the following results depending on the consolidated parameter:

1. None or not provided: The call takes 3 seconds and spits out a warning saying to set the consolidated flag.
2. True: The call fails
3. False: The call takes 15 seconds (5x longer than None) but doesn't warn

Hopefully it's okay if I include the actual code rather than trying to create a test zarr store that reproduces the situation:

```python import s3fs import xarray as xr

top_group_url = 's3://hrrrzarr/sfc/20200801/20200801_00z_anl.zarr' group_url = f'{top_group_url}/surface/GUST' subgroup_url = f"{group_url}/surface"

fs = s3fs.S3FileSystem(anon=True)
ds = xr.open_mfdataset([s3fs.S3Map(url, s3=fs) for url in [top_group_url, group_url, subgroup_url]], engine='zarr', consolidated=None) ``` Note that if I remove top_group_url, consolidated=False returns as quickly as consolidated=None and gives the same results (so it's just the top_group_url which is slowing things down, even though xarray doesn't load any data from it). However, if I only pass top_group_url, xarray loads the dataset in like 300ms, it's just empty.

What I expected to happen:

1. I would expect that providing top_group_url (where the .zmetadata file is located) would speed up the call and prevent the warn from happening when consolidated=None, since obviously the metadata is actually consolidated.
2. I wouldn't expect to be able to construct a call where with any possible value of consolidated, it either warns, fails, or is really slow––and the warning directs me to either change to one of the calls that fails/is slow or to update the data store, which I don't have write permissions to.
3. I would expect the data store to be efficiently and easily read using xarray since it was written by xarray.

Anything else we need to know?:

This zarr store cannot be (usefully) opened by xarray without using open_mfdataset due to an issue I brought up in discussion #5584 which no one has replied to so far. Basically, the person creating it assumed that if they used xarray to write it, xarray would have no problem reading it, but since there's a slash in the variable names, xarray created it as a deeply-nested zarr store instead of a store with each variable as a single-level (sub)group that xarray would have been able to handle.

Each variable was written like this:

python ds.to_zarr(store=store, group=i, mode='w', encoding=encoding, consolidated=True) In the example, "surface/GUST" is the variable name.

Environment: