Ft/docx rendering, RE: #304

[NyanHelsing]

This is an update to https://github.com/CenterForOpenScience/modular-file-renderer/pull/304

Ticket

https://openscience.atlassian.net/browse/SVCS-488 OSF side PR: https://github.com/CenterForOpenScience/osf.io/pull/8002

Purpose

This ticket replaces https://github.com/CenterForOpenScience/modular-file-renderer/pull/282. Credit goes to @AddisonSchiller 🎆🎆.

.docx rendering is very intensive on the OSF. By using Microsoft's online rendering service to render publicly available .docx files, we can remove a lot of pressure from the unoconv container.

Changes

• Added support for public renderers.
• Added the office365 renderer under the public renderers.
• Added support to parse for a public_file query param. This query param is optional.public_file=True denotes that the file is public (the project it belongs to is public) , while public_file=False denotes that it is private. All other values for public_file cause errors to be raised.
• ProviderMetadata now has an is_public flag, with default value set to False.

Side Effects

• Does Microsoft enforces a rate limit?
• How can we handle the "a few hour" cache problem?
• What if this external service is down? Should we detect in advance?
• iframe sandboxing may cause issue, need to verify on staging.

QA Notes

The Office365 renderer does not use the.pdf renderer like unoconv used to, so the pdfs that get made by this renderer may not display exactly the same. More QA notes to come. There is also a README.md in the renderer with more information about testing.

Deployment Notes

• [x] OSF side must be deployed first (no side effects).

[coveralls]

Coverage decreased (-0.2%) to 71.042% when pulling edc9c184c1fc2db2adfaf186d4915589ecfc5211 on birdbrained:ft/docx-rendering into d15d3224c522958d63ea8470c55879e53fa2176f on CenterForOpenScience:develop.