feat: improve attachment storage for API

[cheywood]

• Attachments are stored in note-specific folder
• Attachment filenames are retained

This mirrors the behaviour for attachments created in the web UI, bringing the following benefits:

• Attachments get deleted (edit: and moved) along with the note
• Attachments don't clutter the directory alongside the note
• Non WYSIWIG editors which consume the API provide a better experience (via filenames not being replaced by random strings)
• Consistency with web

Most of the code is based on what's used in Text.

If the API wasn't already public I would switch the name of the return element for image creation to path (from filename). As there likely isn't any project consuming the API yet this may not be a bad idea.

Addresses part of #1623.

[enjeck]

Thanks for working on this and for raising question at #1623. I need time to read through the previous discussions when the current API was implemented before I can properly review this

[cheywood]

Thanks @enjeck! 🙏

Once this is resolved I'll get a release of Iotas out using the API :)

[cheywood]

Oh hrmm yeah reading back through the discussion I picked up that this impacts moving notes between categories too; without this fix the attachments are left in the previous location, disconnected from the note.

[enjeck]

I picked up that this impacts moving notes between categories too; without this fix the attachments are left in the previous location, disconnected from the note.

Yes, also previously reported at #1470

[enjeck]

Like I mentioned at #1623 (comment), I like the idea of using the original file name instead of a random text. But concerned about the new link structure. Apart from the concerns with using the file ID, I wonder how backwards compatible it is. I wonder if it's easier to just keep the existing struture in the meantime and instead explore moving things around when the category is changed.

[cheywood]

Like I mentioned at #1623 (comment), I like the idea of using the original file name instead of a random text. But concerned about the new link structure. Apart from the concerns with using the file ID, I wonder how backwards compatible it is. I wonder if it's easier to just keep the existing struture in the meantime and instead explore moving things around when the category is changed.

Responded over at #1623