Fix a bug in get() requests which occurs when using slower destination devices for retrieved files. In some circumstances, attempting to access a downloaded file immediately after download would result in errors because file contents had not yet been fully flushed and stream cleaned up. The fix was to change the event used to resolve the get() promise to use the finish signal on the write stream rather than on the read stream. Previous version used the read stream signal because in some use cases, the client code does not want to close the write stream. Fix now looks to see what options have been passed in to get() and will use the write stream events when it can and only use the read stream events when this is not possible. This could still result in errors when the client has decided to explicitly manage the write stream, but in that case, it is also down to the responsibility of the client not to attempt to access the downloaded data until they have cleaned up the streams correctly.