Simplify concept of "default file store"

[Jason Gerard DeRose]

As we charge ahead to that glorious day when we bless Dmedia as "production ready", I've been keeping my eye out for poor design decisions that I don't want us to have to live with.

Although after we declare Dmedia production ready we still might make incompatible changes to the schema, etc, we will only do so with an extremely well tested way of losslessly migrating the user's data. As incompatible changes will become so expensive to make, we want to be aggressive about eliminating warts now while it's still cheap and easy.

One of the warts I want to fix is the overly complicated idea of a "default file store". In a pro setting (say when used by a DIT), Dmedia will be managing several entire hard drives. They could be removable, or internal drives mounted in /srv/ or some such. But the key is you work with storage entire drives at a time, and the .dmedia dir would be in the root directory of each drive's file system. I think our design here is very good.

Then there is the special case of the "default file store" on your system drive. Currently there are 3 states for the default store. It can be "shared" meaning it uses /home/.dmedia, or "private" meaning it uses /home/username/.dmedia, or it can be "none", meaning there is initially no file store and you get just whatever file stores happen to be on currently connected removable drives in /media.

Changes I want to make:

* Remove use of /home/.dmedia altogether. Originally this was a stop-gap for us when using Dmedia at UDS, because it was handy for multiple user accounts to be able to access these files, plus I was using ecryptfs for my user folder, which has a fairly big performance overhead. At some point we might add some kind of "shared" file store back into Dmedia, but for now I think it's not worth the complexity. So this means we remove the dmedia.postinst script that creates this directory, and we change Core to no longer use this location.

* Move the "private" file store location from ~/.dmedia to ~/.local/share/dmedia/.dmedia. There are 2 reason to do this. For one, it makes it easier to unit test dmedia-service if it puts all its data inside a single directory. And two, this will make it possible to test and demo Dmedia using the Ubuntu Guest Account. The guest containment doesn't let us create ~/.dmedia, but we can create ~/.local/share/dmedia and any directories therein just fine. We want it to be easier for our testing community to be able to test Dmedia from a clean state, without any risk of harming their personal data, and the Guest Account is a fantastic way to do this.

* Remove the "none" state, make it so the default store is *always* present. The whole reason for "none" was so you could have the importer only create copies on your removable drives, and not fill up a small internal HDD or SSD. But I think this was the wrong approach. Instead, I think the default store should *always* be in the storage pool, but with added control over which drives the importer uses. Right now the importer is kinda dumb and will create a copy on every connected file store.