Update cookbook-plugin to latest revision

- Buck: Add license parameter to maven_jar() invocation
- Implement standalone Buck driven build on top of gerrit_plugin()
  bucklet

Change-Id: Ic5a80478c5ddc634fcc276eff0f21d557576b662
Use existing gc LOG_NAME constant

GarbageCollectionRunner had its own constant for gc log name, use
the one in GarbageCollection instead.

Change-Id: I7f82075841c6a85cc1335878827b4af3277d560d
Refactor system log creation to remove code duplication

Error, gc, http and ssh logs are created programmatically but the
code to create the appender was duplicated.

Move appender creation code into SystemLog to remove
duplicated code and allow to reuse it to create another log.

Also move LogUtil.shouldConfigureLogSystem into SystemLog class.

Change-Id: Ic691e573c3bcd74b4cb77905a176773540235f1a
Merge "Use existing gc LOG_NAME constant"
Serve latest version of plugin resources when cache is stale

When serving HTTP plugin resources from cache,
we do need to check the cached lastModifiedDate
against the underlying plugin entry latest update.

If dates do not match, we need to fetch again the
entry and return it back to the client, updating
the in-memory cache.

Without this fix, the in-memory cached copy was
always returned even if the one on the file-system
was actually updated.

Change-Id: I36ee9989ade0640fb5ceda73749efb852d6c5801
Move change row version bump to commitMessageNotForChange()

I5d7fb4cc resolved this merge conflict of the change in stable-2.9
(which did not have this helper method) in a slightly more verbose way
than necessary.

Change-Id: I1f09b712ae1a34d2c49f3507e1440373811677f9
ChangeInserter: always commit ChangeUpdate

ChangeUpdate.commit() is by design a no-op if no updates were made to
the change, so no need to check before calling.

Change-Id: Ic7b657553e28c2f0ce81d48e06e0a9c9d430a0d9
ChangeInserter: fix comparison of Change.Id to Change.Key

Change key types and method names are confusing, and Java's
Object.equals() was not helping us here. As a result we actually ended
up inserting the same ChangeMessage multiple times, which depending on
the gwtorm backend might or might not have succeeded.

This combined with I5d7fb4cc had the interesting consequence of racing
the row version update with the background mergeability flag update.
If the row version update won, it would have the effect of erasing the
result of the mergeability check, causing spurious "Cannot merge"
warnings.

Change-Id: I8aeb0c87bb2475fa9b49685d27ded48059295547
Return changes from mergeable in ChangeJson only if tested

If background mergeability checks are not working for some reason, we
should not blindly report that changes are unmergeable. We have enough
information stored in the change, namely the last SHA-1 tested
against, to know whether a check was ever successfully run. Take
advantage of this in ChangeJson.

Change-Id: I4df800d66ac929e9cd152795acd9f5b671bfd101