use hmac in balanced preferred content

This deals with the possible security problem that someone could make an
unusually low UUID and generate keys that are all constructed to hash to
a number that, mod the number of repositories in the group, == 0.
So balanced preferred content would always put those keys in the
repository with the low UUID as long as the group contains the
number of repositories that the attacker anticipated.
Presumably the attacker than holds the data for ransom? Dunno.

Anyway, the partial solution is to use HMAC (sha256) with all the UUIDs
combined together as the "secret", and the key as the "message". Now any
change in the set of UUIDs in a group will invalidate the attacker's
constructed keys from hashing to anything in particular.

Given that there are plenty of other things someone can do if they can
write to the repository -- including modifying preferred content so only
their repository wants files, and numcopies so other repositories drom
them -- this seems like safeguard enough.

Note that, in balancedPicker, combineduuids is memoized.

doc/todo/git-annex_proxies.mdwn

@@ -42,12 +42,6 @@ Planned schedule of work:
   not occur. Users wanting 2 copies can have 2 groups which are each
   balanced, although that would mean more repositories on more drives.
 
-* picking a low UUID and picking keys that mod N == 0 would let an attacker
-  generate keys that balancing always puts on that UUID. To avoid this
-  use HMAC with the set of UUIDs and the key. Then any such attack can be
-  prevented by adding another UUID to the set, it could even be a dummy
-  UUID that is marked as having 0 size, so it will never be used.
-
 * document balancing algo well enough that someone else could implement it
   from the design doc