Refactor how file uploading works

[jmcameron]

Our current approach to file uploading puts the uploaded files into the bin directory.

When setting up a new site, the command 'yarn build' deletes the 'bin' directory and copies over files from clients/src/assets to bin/client/assets, etc. But files previously uploaded to the bin directory will be lost. This may not be a problem for production sites since we never expect do 'yarn build'. However for developers, when we download a production site, we only get the database, not any downloaded files. This means developers will have references to non-existing files. Generally this is not too much of a problem, but it does complicate testing.

Note that this also affects the online versions of the production sites (eg, imck.bhi.ma) since the online sites get the latest databases, but not the uploaded files from the production sites.

Per a conversation with @jniles , we should reconsider how this works. One possible approach is to specify and upload directory outside the Bhima installed files (eg, under bin). This means 'yarn build' would not delete that directory. If developers need to test something related to uploaded files they can download the files separately from the upload directory.

[jniles]

@jmcameron thanks for writing this up.

Yes, filling in some details here...

The actual upload directory should be configurable via the .env file. By default, I would promote using something like ~/.bhima/ or similar to store BHIMA assets. That way, no matter where we put our BHIMA installation, we won't break references to our uploaded assets or saved reports.

I can imagine two:

1. ~/.bhima/uploads - for the uploaded assets from a client
2. ~/.bhima/reports - for the saved PDF reports

This would make things easier to back-up and migrate BHIMA versions without being scared you might accidentally hose the institutions reports.