Fix up a race condition in the aggregator test.

The code assumed that 'go a(); go b()' would always call a() first, but that isn't
guaranteed by the runtime.
There was a bunch of other code that happened to work because of bad assumptions, so
I went around and cleaned them up (it assumed that it was ok for results to be of length
100 when making a request for 10 ids, which only worked because the aggregation code looped
over the input rather than looping over the result of the request).
Add some trace level logging which will hopefully help us understand why the
machine address updater keeps saying that it is updating addresses with values that haven't changed.
Address bug #1362453.

When storing the addresses of a Machine, we won't ever want to use the ScopeLinkLocal addresses,
both PublicAddress and PrivateAddress will explicitly filter them out, and they just confuse things
when dealing with addresses (at one point they were candidates for Clients to try to connect to
the API server).
review comments from Dimiter
Merge pull request #627 from jameinel/ignore-link-local-1362453

Ignore Link Local Addresses

This addresses 3 different issues, I can split them up if requested, but it is easiest to just land them together.

1) Race condition in aggregate_test.go. It had an assumption that:
  go funcA()
  go funcB()
would always call funcA before funcB. (Because the result list was a fixed response, and the processing code doesn't do any mapping of result ids to actual request ids.)
There was a fair bit in other tests that only really worked by happenstance, so I cleaned them up as well.

2) Add some Trace level logging about why 2 address lists don't match. I've seen a bunch of log entries that say "updating machine addresses" when nothing appears to have actually changed.

I can just shelve this, and instead only test manually and see if I find a fix, but I figure that trace level logging is cheap.

3) Actually fix bug #1362453 which is that when looking at Machine addresses, we include their LinkLocal address. Which isn't a useful address in any sense. And right now both PrivateAddress and PublicAddress take care to filter them out. However I thought it might be part of why (2) is getting confused, and certainly in the past I was seeing them end up in the list of APIHostPorts which is a bit silly (there is no reason to say that you can connect to a machine on its LinkLocal address.)