File operations for custom storage volumes

[lahariguduru]

Finished Get and set up API Endpoint for issue #1527. This has been checked between client and daemon, and successfully executes the command.

[stgraber]

Looking into this one

[stgraber]

Did an initial cleanup pass, fixing the missing comments (reported by Code tests) and removed an incusd binary as well as a couple of test files that were mistakenly included into your branch.

[stgraber]

Also re-generated the translations as that's needed when adding a new command.

[stgraber]

Also found some debug comments and added some missing line breaks.

[stgraber]

And also re-generated the API documentation.

[stgraber]

Okay, I've done enough cleanup that you can see the expected structure for this.

Now for the actual review.

This PR is extremely incomplete. The issue refers to implementing a file API similar to that for instances, this means:

• incus storage volume file create
• incus storage volume file delete
• incus storage volume file edit
• incus storage volume file mount
• incus storage volume file pull
• incus storage volume file push

At the API level, that means supporting:

• GET /1.0/storage-pools/POOL/volumes/custom/VOLUME/files?path=/XYZ
• POST /1.0/storage-pools/POOL/volumes/custom/VOLUME/files?path=/XYZ
• HEAD /1.0/storage-pools/POOL/volumes/custom/VOLUME/files?path=/XYZ
• DELETE /1.0/storage-pools/POOL/volumes/custom/VOLUME/files?path=/XYZ

As well as having a SFTP endpoint at: /1.0/storage-pools/POOL/volumes/custom/VOLUME/sftp

The CLI should be based on what we have for instances (code should be shared, no need to duplicate it) and similar to instances, the CLI should just use SFTP, not the slower /files API, that's for scripting.

All the API endpoints should behave identically to their /1.0/instances/NAME/files equivalent, same headers, same content type, ... Similar to the CLI comment above, the server-side logic should be shared, so it should really be about moving some code into helpers and then calling it from both the instance and custom volume endpoints.

And we obviously need some tests for this stuff too.

[stgraber]

Looks like the right general areas of the code have been identified, but now this needs to be fully fleshed out with a real files API including SFTP support and client and CLI functions that match those already there for instances.

The net new code for this feature should be pretty minimal. All the needed client side and server side logic already exists for instances, the logic in question needs to be moved to common functions that can be called with the relevant path (either the container's rootfs or the custom storage volume's path).

[stgraber]

Moved the issue back to draft. Please mark it as ready for review when the remaining bits have been implemented.

[stgraber]

I'm now looking into #2071 which will address part of this issue (there's overlap between the two). If we can get the /sftp endpoint and incus storage volume file mount implemented through that one, that'd leave the full /files API for this one as well as the remaining command line helpers (which would use the /sftp endpoint).