Go back to requiring a count and size up front, but better track and
display files that are skipped because they don't need to transfer. This
makes it easier to judge what is happening based on the progress output.
This is a fix for a bug in the handling of the GIT_LFS_PROGRESS file
which is used by desktop apps, or other things integrating with the
git-lfs binary.
At a later point, we should move toward a more unified progress tracking
which supports this file as well as the pb progress bars via a single
API.
This lets the api client code broadcast success/fail events that the
upload queue can listen for. The queue will process synchronously until
it receives a success event, then it will run concurrently.
To prevent being asked for credentials n times (where n = # of
concurrent uploads), we process the upload queue synchronously until one
of the uploads succeeds, and then allow concurrent uploads.
This could be a bit faster if the condition is fired after the first
successful API hit, rather than the first successful total upload, but
some deeper refactoring will need to be done.
If wg.Add is called from the loop reading from the channel, there are
scenarios (number of uploads <= number of workers) where Wait() will
shut down the channels before they're read from.
