Enhance quota exceeded logging for admins

[joshtrichards]

• Resolves: [Bug]: Insufficient Storage Error does not name user (nextcloud.log, android, desktop) #37519

Summary

Enhances quota exceeded server-side logging for administrators by adding:

• target folder owner name (i.e. when shared)
• indicator of user quota (vs disk space) issue

Context: The existing Insufficient space error logging doesn't indicate the folder owner (which is important since the sharee path is what's logged). In addition, quota issues are addressed differently than, say, disk space issues so administrators benefit from quickly noting the type of Insufficient space issue occurring.

Applies to file/folder operations: uploads, moves, copies

Also:

• improves - indirectly - the user-facing messaging when uploading (only*)
• Doesn't include the owner when it's useless (i.e. not shared)

Addresses backend portion of #37519

*Currently working on independent (but related) PRs to unify frontend messaging with same target folder owner inclusion (when applicable)

TODO

• Review code

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[joshtrichards]

For the record...

Existing log entry for all quota issues:

Insufficient space in /Project/Videos/lightonflux, 27136230 required, 343725 available

New (where owner is applicable):

Quota exceeded in /Project/Videos/lightonflux (owner: sarah), 27136230 required, 343725 available

New (where owner is inapplicable but there's still a quota issue):

Quota exceeded in /QuotaTest, 341471232 required, 301045000 available

[szaimen]

/rebase

[szaimen]

tests failing...

[joshtrichards]

Fixed (at least for me... we'll have to see what the tests say).

In the quota plugin, depending on which before* operation is being called, sometimes checkQuota() gets handed a $path that includes the basename of the URI and other times not so much.

That's current behavior so I'm leaving it be, but I added a check for non-chunked uploads in checkQuota() now just before the getOwner() call in this PR (and then I adjust the $path to exclude the basename). That way we always gets a workable $path for non-chunked uploads (and, more importantly, the same as we'd have gotten if it had been a chunked upload)

The main reason non-chunked uploads triggered this is because the PUT operation never finishes (since the quota is exceeded) so there's really no file to check ownership of - all we have is the intended folder.

All my manual testing was apparently based on doing >10 MB uploads. And the way that chunking-v2 uploads work, the MOVE was giving us what we expected for $path. But <10 MB uploads just do a straight PUT and we receive the full path with the filename intact for the quota check. The integration tests failing all seem to be <10 MB (non-chunked).

[joshtrichards]

Incidentally this also fixes a "cosmetic" bug as a side effect versus current master behavior where hitting quota with uploads in the root folder were being mishandled in the logging/notifications:

Before:

After:

I'd noted this during various bits of testing but hadn't gotten around to checking for prior reports of or root causes for - so that's a nice benefit to this change even if it wasn't the target of (or caused by) this PR. Woohoo!

[skjnldsv]

What's the status here @joshtrichards :)