progress: do not block on async filesystems

[isidentical]

When an async filesystem (fsspec-level) makes a call to set_size() callback with None (the size is not inferrable), we call the info() on the dvc-level sync filesystem which delates this call to fsspec's async function run in a separate loop. This situation is creating a deadlock where we make a call from an async function (e.g _get_file) to another async function (_info) with a wrapped sync execution (info()) between them.

For the simplicity, this patch drops the current behavior of consulting to info() on set_size(None).

[efiop]

@isidentical Personally, the second option seems to be way too convoluted and looks out of place in the callback itself. The first option seems nicer. But I'm not sure I fully understand

But for example, for goole storage, it might not find the size among the headers but can find it on a HEAD_OBJECT call.

could you elaborate, please?

[skshetry]

I have gone through other filesystems and have been doing fs.getsize for callback support (we were doing this anyway for tqdm progress bars in upload/download). I think we should be able to remove this and replace with explicit calls in the future.

[isidentical]

Personally, the second option seems to be way too convoluted and looks out of place in the callback itself.

I also feel that way.

could you elaborate, please?

For example this is how gcsfs calls the set_size callback, which might get None if the server doesn't include headers. The same might go to HTTP, where the GET request might not contain the content-length, but the HEAD can. So if the set_size() is called with None, we call info() to retrieve the size in the proper way (for gcsfs, we make an HEAD_OBJECT API call, and retrieve the object's size from that call's result, not from header).

[skshetry]

Hmm, that's weird. I'd expect Google Cloud Storage to provide a uniform response, unlike HTTP servers.

[isidentical]

From what I have observed, it does on the cases I have tried. This was just an example of what could have happen if it didn't (or another provider didn't, e.g a mock server).

[efiop]

@isidentical if mock server doesn't provide it - it is a bug in the mock server and it should be fixed to follow the behaviour of the real thing. So we probably don't need to overengineer it like that and could use a simpler option.

[efiop]

So looks like we no longer need self.fs and self.path_info anymore?

[efiop]

btw, please rebase on. top of master, we've increased timeouts for now (though windows taking half an hour is not normal)