feat(nextcloud): Add low-level helpers for WebDavResponse

[provokateurin]

Necessary refactor for #718.
Extension helpers are still there to offload the small part of logic that is useful for consumers (while the rest was just proxy variables).

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 9 lines in your changes missing coverage. Please review.

Project coverage is 28.71%. Comparing base (548176b) to head (efc8823).

Files with missing lines	Patch %	Lines
.../src/api/webdav/utils/webdav_response_helpers.dart	0.00%	9 Missing ⚠️

Additional details and impacted files

@@                         Coverage Diff                         @@
##           test/nextcloud/all-props-parsed    #2561      +/-   ##
===================================================================
- Coverage                            28.71%   28.71%   -0.01%     
===================================================================
  Files                                  366      366              
  Lines                               136274   136280       +6     
===================================================================
  Hits                                 39128    39128              
- Misses                               97146    97152       +6     

Flag	Coverage Δ		*Carryforward flag
account_repository	98.76% <ø> (ø)
cookie_store	99.48% <ø> (ø)		Carriedforward from 548176b
dashboard_app	96.05% <ø> (ø)
dynamite	31.05% <ø> (ø)		Carriedforward from 548176b
dynamite_end_to_end_test	61.69% <ø> (ø)		Carriedforward from 548176b
dynamite_runtime	85.40% <ø> (ø)		Carriedforward from 548176b
interceptor_http_client	97.18% <ø> (ø)		Carriedforward from 548176b
neon_dashboard	96.05% <ø> (ø)		Carriedforward from 548176b
neon_framework	59.20% <ø> (ø)
neon_http_client	97.50% <ø> (ø)
neon_notifications	100.00% <ø> (ø)		Carriedforward from 548176b
neon_storage	94.66% <ø> (ø)
neon_talk	99.45% <ø> (ø)		Carriedforward from 548176b
nextcloud	24.31% <0.00%> (-0.01%)	⬇️
notifications_app	97.40% <ø> (ø)
notifications_push_repository	98.59% <ø> (ø)
sort_box	90.90% <ø> (ø)		Carriedforward from 548176b
talk_app	98.94% <ø> (ø)

*This pull request uses carry forward flags. Click here to find out more.

Files with missing lines	Coverage Δ
.../src/api/webdav/utils/webdav_response_helpers.dart	0.00% <0.00%> (ø)

[Leptopoda]

I was also thinking a lot about removing the webdav file abstraction and rather have something based on package:file in a separate repo.

Is there a way we can do this without breaking the api?
We should deprecate the webdav file abstractions and give devs time to migrate (given that this is the most used code of the nextcloud package).

[provokateurin]

I was also thinking a lot about removing the webdav file abstraction and rather have something based on package:file in a separate repo.

Sounds good, but the nextcloud package wouldn't know about this abstraction, right?

Is there a way we can do this without breaking the api?
We should deprecate the webdav file abstractions and give devs time to migrate (given that this is the most used code of the nextcloud package).

I need to get rid of this for CalDAV/CardDAV support, so if we deprecate it now we will have to wait a lot longer until we can support those as well.
While deprecating it for now and removing it later would be nice, I think it is fine since there is an easy path to migrate.

[Leptopoda]

Sounds good, but the nextcloud package wouldn't know about this abstraction, right?

For the idea I head yes.

I need to get rid of this for CalDAV/CardDAV support, so if we deprecate it now we will have to wait a lot longer until we can support those as well.

Then just duplicate the code and implement the new low level api separately.
You can also keep the low level api internally for now and just base CalDav and CardDav on it, deprecating the WebdavFile at a later point.

[Leptopoda]

Should we even keep the PathUri abstraction or just make it work on strings?

[Leptopoda]

What is the typical prop count on a file? How expensive is this operation?

The second commit calls file.props multiple times subsequently.
I don't have any issue in keeping it like this and require the user to cache the prop themselves.

[provokateurin]

There are usually two propstats (one 200, one 404). This could also be changed to a firstWhere to be slightly cheaper.

[Leptopoda]

Why don't we just make these helpers available on the WebDavResponse directly?
I understand that this will make the generation a bit harder, but it also allows us to cache these operations.

[provokateurin]

Sure, I can give it a try. Caching is indeed a good reason to move it inline.

[Leptopoda]

Why the null assertion?

[provokateurin]

There can be responses without a href which are not valid. Consumers need to filter these out (we already did in toWebDavFiles()) and then we need to prevent null hrefs here.

[Leptopoda]

But this means that unfiltered responses will throw here.
I'd rather return a null when there is no href.

Then the filtering can be done based on the path.