Implementing intraline edits.

Coloring intraline edits according to the Spans in DiffInfo.

Change-Id: I3a907e0e4b9c401da87b848eea35285c437da706
Respect draft visibility when determining visibility of all refs

When determining whether or not all refs are visible, drafts were not
considered. Thereby, non-visible drafts could get pulled, or
non-visible drafts were browsable through gitweb.

As drafts are refs as well, we now check their readability as well,
when trying to determine whether or not all refs are visible.

This change makes 'View Drafts' permission mandatory to use the
internally managed gitweb, as there is no way to hide drafts from
there.

Change-Id: Id064c38986b667d00a8adcfcb4a31fc04f25cc23
Allow adding patch sets only to visible changes

Thereby, we prohibit adding patch sets to invisible drafts of others.

Change-Id: I7d942ccde77e8e779a87ef5b3862404bd3632365
Stop advertising non-visible changes when receiving commits

Change-Id: I2d313aa7c768105426e94a2e7949740e8c1c3c94
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