:bug: Use django collectstatic

[obrenckle]

Problem

• The yunohost app was using the development locations for static files. As some of these had the python version in their path, but no specific python version was specified for the app, some of the paths could end up using "pythonX.Y" when the real path was "pythonX.Z".

Solution

• Add a function calling django collectstatic action
• Call said function in some of the app scripts (install, upgrade and restore)
• Serve all static files from the new location (fix #23 )

PR Status

• [X] Code finished and ready to be reviewed/tested
• [X] The fix/enhancement were manually tested (if applicable)

Automatic tests

Automatic tests can be triggered on https://ci-apps-dev.yunohost.org/ after creating the PR, by commenting "!testme", "!gogogadgetoci" or "By the power of systemd, I invoke The Great App CI to test this Pull Request!". (N.B. : for this to work you need to be a member of the Yunohost-Apps organization)

[Tagadda]

!testme

[yunohost-bot]

Meow :cat2:

[obrenckle]

I see what happened:

1. collectstatic waited for input when files where present

Easy enough to correct

2. I assumed that env_path was an helper/environment variable was in fact set in another script that isn't called during restore

Setting the variable is simple, but I could use some advice. The restore task doesn't recreate the python virtual environment, it only extract existing files from the backup, which is fine if the restore is happening in exactly the same conditions than the backup, but I'm wondering what would happen the app was restored on different hardware/OS. Wouldn't it be easier to recreate the python virtual environment during restore ?

[obrenckle]

I fixed the errors and tested the PR with package_check this time. There's still (ignored) errors during two "Upgrade from specific commits" tests, but these happen during the initial install (so from the old commits), so I can't do much there.

[Salamandar]

I rebased the branch after the packagingv2 port.