ARXIVNG-992 Implementation of integration with file management service

[erickpeirson]

This is based on https://github.com/cul-it/arxiv-filemanager/blob/b809d22a83510e9698cb4191978b6b4c3c134531/schema/openapi.yaml

I wrote a few tests with a mock file management app, but didn't want to get too far down that road until response structure is known. At this point, it probably makes sense to review this for correctness (consistency with the OpenAPI spec), and then build out error handling/tests further when the content spec is known.

[erickpeirson]

Changed base to task/ARXIVNG-892, since this branch was forked from there.

[coveralls]

Pull Request Test Coverage Report for Build 199

• 67 of 89 (75.28%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.06%) to 74.77%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
submit/services/filemanager.py	67	89	75.28%
<!--	Total:	67	89	75.28%	-->

Totals
Change from base Build 196:	0.06%
Covered Lines:	649
Relevant Lines:	868

---

💛 - Coveralls

[erickpeirson]

Will delete workspace be available to submitter and act like 'release'? or is this actual delete intended for admins? Maybe this logic is handled elsewhere. I'm wondering if admin commands should be organized together [delete,lock,unlock].

Ah, good catch. I was working through the OpenAPI spec, and not thinking about how these aren't desired in the UI. Will remove.

[erickpeirson]

I believe delete file request should take the relative path from root of submission workspace. I guess file_path argument is slightly misleading though description as key is accurate.

Agreed. Will try to make this clearer in the docstring.