Improved share extension error handling

[michalrentka]

Fixes #893, also in #891 I missed a case, where metadata editing is enabled, but file editing is disabled, in that case, we'd get "unknown" error in share extension too. This time we show proper error all the time. Share extension also cleans up after itself if there is an error, so we don't have any items which shouldn't exist.

[mvasilak]

Looks good, a couple of suggestions/questions.

Regarding switch where cases are specific, it might be better to not use default, but rather explicit cases, so that build complains when a new case is omitted.

If an item shouldn't be created when upload fails, why not perform them in reverse order, i.e try uploading, and if this succeeds, create the item. Is there some edge case I'm not aware of, that is covered by the current workflow?

[michalrentka]

If an item shouldn't be created when upload fails, why not perform them in reverse order, i.e try uploading, and if this succeeds, create the item. Is there some edge case I'm not aware of, that is covered by the current workflow?

So our API requires an item created beforehand, so I have to create an item, submit it to API, then authorize an upload and finally upload the file. So if authorization fails I have to delete the file afterwards.

[michalrentka]

Regarding switch where cases are specific, it might be better to not use default, but rather explicit cases, so that build complains when a new case is omitted.

Agreed, I usually try to do that, fixed it here: 64be7e4.