Bugfix: Prevent music library exchange while loading local/remote music

[hwray]

Right now, we aren't waiting on any of our threads that load music into the library. These include:

• The MusicLibraryLoaderThread, which loads the phone's local music when the app is booted
• The RequestLibraryThread, which requests and loads the music metadata and album art from a remote phone.

We need to make sure of several things:

• When creating a Jam, don't exchange library data with any joining clients until all local music has been loaded from the MusicLibraryLoaderThread.
• When joining a Jam, don't exchange library data with the Master phone until all local music has been loaded.
• When accepting multiple clients in quick succession, the Master phone should exchange music data with the clients in a serialized fashion. (This may not actually be a problem, as we're POSTing each remote library to all clients after loading completely.)

I talked with @JayThomason and we decided these things can probably be easily solved with an exclusive loaderLock that wraps around the relevant code blocks.

[JayThomason]

I implemented the lock solution in the DBHandler that we previously discussed and tested it by accepting requests on the master from two clients one after another as quickly as possible. It seemed to work well -- I watched as one phone loaded just the music from the master and then the other phone loaded the music from the first two and finally the first phone got the forwarded music from the second.

9574b67

[hwray]

I'm going to reopen this for now. It looks like the solution of synchronizing the DB loader methods is causing our UI to freeze up for pretty long periods when new Clients join the jam. We may have to come up with another solution.