Resolved a couple of issues

This PR addresses a couple of issues that have been found during testing on the live system

- less frequent registry updates when uploading the extension download data to the webapp. The current implementation will update one extension with all available download datapoints and save the registry afterwards. The previous implementation had a much finer granularity, where every update of one download datapoint required the registry to be saved. This caused out of memory conditions on my machine (mainly when using the filestorage implementation and corrupted registry.json files)
- provide a `csrf` token to enable upload of extension download data from localhost
- use S3 object key instead of a timestamp to find new logfiles. This key will be used the next time `listObjects` is called
- support paging of results from `listObjects` call (S3 object key is used here too)
- added `coverage` directory to `.gitignore`
Yeah, I think Bluebird will pass along an exception if a rejection handler throws, but I don't think it has any way to deal with this sort of exception (the original async function throwing). This test can just go away.