Introduce state/toolstorage

state/toolstorage provides an interface, Storage,
for storing tools tarballs and metadata in state.
The tarballs are stored in GridFS, while the
metadata are stored in a Mongo collection.

State grows a single new method, ToolsStorage,
which constructs a toolstorage.StorageCloser.
The returned object will store tools metadata in
the "juju" database's "toolsmetadata" collection,
and the tarballs in the "blobstore" database.
On Thu, Sep 4, 2014 at 11:31 PM, ericsnowcurrently <notifications@github.com
> wrote:

> In state/state.go:
>
> > @@ -67,6 +67,7 @@ const (
> >  	openedPortsC       = "openedPorts"
> >  	metricsC           = "metrics"
> >  	upgradeInfoC       = "upgradeInfo"
> > +	toolsmetadataC     = "toolsmetadata"
>
> For backups the collection is not actually part of state (rather just
> making use of state's DB). Hence the following comment and separation. Is
> that the case for tools metadata as well? If so, I'd say toolsmetadataC
> should be grouped with backupsMetaC.
>

Not really sure what you mean by "part of state" vs. "just making use of
state's DB". State is just the database where we store things for Juju's
operation. What's the distinction?

However, from what I can tell it will be used in normal state operation,
> even if it isn't actually part of state. Are there other collections in
> that same boat? Either way it would be nice if
> used-in-state-operation-but-not-part-of-state collections were grouped
> together.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/juju/juju/pull/663/files#r17120738>.
>