Replace the legacy backups implementation with a new one.

The new implementation is refactored to fit to the new backups approach of storing the backups in env storage (along with metadata in mongo). This is the final large patch in the backup series (the remaining ones are much smaller).

The next 2 patches in the series:
https://github.com/ericsnowcurrently/juju/pull/3
https://github.com/ericsnowcurrently/juju/pull/4
Sorry I wasn't more clear.  First of all, create() is an implementation detail of the backups functionality.  The public API wraps create() (its only intended consumer) and is coming in the next patch in the series.

create() returns all the info that the public API will need to do its thing, bundled up in a createResult struct.  That struct contains an open file (io.ReadCloser).

We could have gone two ways with that file, the alternative being returning a filename.  If we return a file then the caller is responsible for closing it when they are done with it.  If we return a filename then the caller is likewise responsible to delete the file.  Nothing in juju needs the file to stick around since we will be storing it in env storage.

Like I said, the public API is the only intended consumer of create(), and it needs a file rather than a filename.  So returning a filename did not make a lot of sense.

Perhaps you are wondering why we don't just return the filename and let the caller open/close it.  I found it cleaner to do it the other way.  Basically, builder.result() gets called at the end of create().  This generates a createResult based on the final state of the builder.  That is the result that create() returns.  However, create() has a deferred call to builder.cleanUp(), which deletes the workspace directory where the backup archive is sitting...promptly after we opened that archive and stuffed it into the result.  That means the file gets deleted, hence there is no valid filename for the file any longer.  That isn't a problem, though, since we already have the open file.

I suppose we could create that archive outside the builder's workspace or copy it outside the workspace in builder.result().  Either way the filename would then be valid.  However, that doesn't seem worth it just for the sake of returning a filename when what we need is an open file anyway.

Hope that helps.