fix open-write-close chatter during SendObject

[js731ca]

The current implementation that handles MTP_OPERATION_SEND_PARTIAL_OBJECT would repeatedly open;write;close during a transfer of a large file.
Which is undesirable when other processes in the system want to register with inotify to watch create/modify/close on a folder/file where access is provided over mtp.

The solution implemented here is to simply keep the file-descriptors around and open over the stream of SendPartialObject chunks.

The order of MTP operations is (or seems to be, always?):
BeginEditObject, SendPartialObject x chunk-size, EndEditObject.
Now the first SendPartial would open() the file, and the trailing EndEdit would then close() it.

# Before:
$> inotifywatch /mnt/data/mtp-storage/
total  modify  close_write  open  filename
33368  29652   1858         1858  /mnt/data/mtp-storage/


# After (uploading a new file):
$> inotifywatch /mnt/data/mtp-storage/
total  access  modify  close_write  close_nowrite  open  create  filename
29696  10      29669   3            5              8     1       /mnt/data/mtp-storage/

# After (overwriting the same file):
$> inotifywatch /mnt/data/mtp-storage/
total  modify  close_write  open  filename
29692  29690   1            1     /mnt/data/mtp-storage/

---

The first couple of commits only refactor/deduplicate/move code around - and are (intentionally) split into small parts for ease of review ;-)
The last commit is the change this PR is actually interested in.

CC @bith3ad @gujie-leica

[jfdelnero]

I didn't checked the modifications yet, but have you tried to do some unexpected disconnections or similar tests to check that the file(s) are correctly closed by umtpd ?

[js731ca]

I didn't checked the modifications yet, but have you tried to do some unexpected disconnections or similar tests to check that the file(s) are correctly closed by umtpd ?

very good point - not yet, will do!

[js731ca]

your intuition was spot on: there was one line missing to cleanup/close stale file handles - added with 5a26ef1
what i've also (now) tried was to simply abort the file transfer, as well as physically disconnecting the usb cable - both looked Ok: in the first case the file handle was still open until the next mtp operation comes around, which is IMO expected since the device can't know if the transfer just stalled or was aborted, the second scenario closed the gadget side and did the cleanup