In case of early ejection of SD card, allow "closing" RawFile handle anyway

[peterkrull]

It seems that there is no nice way to get rid of a RawFile handle if for example the SD card is ejected, since calls to crate::VolumeManager::close_file will result in a returned error before the file id is removed from the open_files list.

In my testing, I have implemented the following:

if volume_mgr.write(file, data.as_slice()).is_err() {
    volume_mgr.destroy_file(file).unwrap();
    volume_mgr.close_dir(dir).unwrap();
    volume_mgr.close_volume(volume).unwrap();

    continue 'setup; // Loop back and retry connecting to card
}

where

/// Destroy a file for the given RawFile, without updating its entry.
/// This can be useful if the SD card is suddenly ejected, and one must
/// notify the VolumeManager that we are dropping the handle.
pub fn destroy_file(&mut self, file: RawFile) -> Result<(), Error<D::Error>> {
    let file_idx = self.get_file_by_id(file)?;
    self.open_files.swap_remove(file_idx);
    Ok(())
}

Which works nicely. Another option would be to modify the close_file method to first get the index, remove from the list, and then try to update the entry by flusing (as implemented in #121):

/// Close a file with the given full path.
pub fn close_file(&mut self, file: RawFile) -> Result<(), Error<D::Error>> {
    let file_idx = self.get_file_by_id(file)?;
    self.open_files.swap_remove(file_idx);
    self.flush(file)?;
    Ok(())
}

[thejpster]

I think close should always close a file, regardless of whether it was able to flush it.

[peterkrull]

I think the simplest solution is to simply not short-circuit the file-flush, then remove the file index, then return the result of the file-flush

[peterkrull]

Closing in favor of #123