Performance (& security?) fixes in AdvertiseRefsHookChain

Since BaseReceivePack.setAdvertisedRefs() only allows
us to shrink the number of refs and not the advertisedHaves
(objects advertised to the client) a few big issues arises.

First, let's look at ReceiveCommits (filtered out some stuff)
where we build the chain:

   if (!projectControl.allRefsAreVisible()) {
      rp.setAdvertiseRefsHook(new VisibleRefFilter());
   }

   List<AdvertiseRefsHook> advHooks = new ArrayList<AdvertiseRefsHook>(3);
   advHooks.add(new AdvertiseRefsHook() {
     public void advertiseRefs(BaseReceivePack rp)
          throws ServiceMayNotContinueException {
        allRefs = rp.getAdvertisedRefs();
        if (allRefs == null) {
          allRefs = rp.getRepository().getAllRefs();
        }
        rp.setAdvertisedRefs(allRefs, rp.getAdvertisedObjects());
      }
   });

  advHooks.add(rp.getAdvertiseRefsHook());
  advHooks.add(new ReceiveCommitsAdvertiseRefsHook());
  rp.setAdvertiseRefsHook(AdvertiseRefsHookChain.newChain(advHooks));

All these three AdvertiseRefsHooks will contribute objects
to BaseReceivePack.advertisedHaves through rp.setAdvertisedRefs().

While we filter down our refs, the objects will stay in
BaseReceivePack.advertisedHaves; generating a massive amount of objects
to be marked as "uninteresting" in checkConnectivity(). With the slow
pending queue in the RevWalk, JGit does not scale very well with these
amounts of objects in advertisedHaves.

Part of setAdvertisedRefs() for reference:

  refs = allRefs != null ? allRefs : db.getAllRefs();
  refs = refFilter.filter(refs);

[...]

  for (Ref ref : refs.values()) {
	if (ref.getObjectId() != null)
		advertisedHaves.add(ref.getObjectId());
  }
  if (additionalHaves != null)
	advertisedHaves.addAll(additionalHaves);
  else
	advertisedHaves.addAll(db.getAdditionalHaves());

By just pre-filtering the refs and calling setAdvertisedRefs()
just once, we could cut the push time down to 1/3 of what we have
today.

This is the difference between push times when applying this
patch (+ warm caches):

Before patch: 0m41.476s
After patch: 0m13.833s

I'm also wondering if the excessive amount of objects in
advertisedHaves means it can be possible to reference
commits that is not supposed to be seen or reached by the user.

Change-Id: Ice158efbc03d6e80576ad87f499777b7381bd0fa