Use storage classes to manipulate image uploads

[diox]

Fixes mozilla/addons#16060

Context

Back in 5699608 we started validating upload_hash to prevent potential path traversal issues. This adds an additional more robust layer of protection by avoiding os.* operations and making sure we use storage with the appropriate root when uploading images.

Drive-by

• Removed obsolete migrate_user_photos command
• Added accept attribute to icon & previews upload flow (I kept uploading icons & previews over and over again and was tired of seeing files that are not valid in the file browser)

Testing

• Upload some icons and screenshots. It should still work.
• Bonus point:
  • Edit the code to remove the validation around icon_hash added in 5699608
  • Edit media for an add-on, browse for a new icon, but don't save yet
  • Using devtools, find upload_icon_hash hidden input. Its value attribute should be a hash.
  • Modify that value, setting it to ../../../../storage/.../path/that/exists. For instance, if you have an avatar for your user with id=1, try ../../../../storage/shared_storage/uploads/userpics/01/0001/1/1.png
  • (Keep devtools opened, look at XHRs under Network tab)
  • Hit save. This should generate a 400 error. If you have DEBUG=True, you should see the response for that 400 should be a SuspiciousFileOperation error.

[eviljeff]

Can source ever be == to dest_file? I.e. is it a redundant if condition? (similarly below in resize_preview)

[diox]

Yes - in fact I realized writing this patch that there is a slight difference between how devhub and the API works here: devhub saves a temporary file path which is passed to the resize_preview/ resize_icon task, where as the API directly saves the file to the original path and calls the task with that "original" path - removing the need for the extra move/rename.

That's something we might want to look into later, but I didn't want to change that here.