Avoid CodeReviewCommit.error() whenever possible

The instances returned by this static factory method are severely
limited, in that they are not tied to actual commit objects. In most
cases, we can tie them to commit objects, so do that whenever
possible. Limit the statuses that we can pass to this method by
making it private, and creating separate factories only for those
statuses where there is really no commit.

Change-Id: I0cb392f4f7f5134d4a7487a2a7bb7ac9d770f334
Pass ChangeControl into CodeReviewCommit error instances

Within MergeOp these are keyed by Change.Id, but some error handling
code only receives the CodeReviewCommit and not the ID. That code is
reasonable in assuming there is a change/notes/control available, so
ensure this is the case when creating error instances.

Bug: issue 2911
Change-Id: If65398652f0e5b1a2b10a2fadc9a3b74bce7d556
Fix IncludingGroupMembership.containsAnyOf infinite loop

This class is using a map to store the memberOf and can be accessed
by multiple threads concurrently. The map was not synchronized which was
causing an infinite loop under very specific sequence of events. Here is
a snippet of the thread dump when that problem happened:

"SSH gerrit review ..." prio=1 RUNNABLE
java.util.HashMap.getEntry(HashMap.java:446)
java.util.HashMap.get(HashMap.java:405)
com.google.gerrit.server.account.IncludingGroupMembership.containsAnyOf(IncludingGroupMembership.java:77)
com.google.gerrit.server.account.UniversalGroupBackend$UniversalGroupMembership.containsAnyOf(UniversalGroupBackend.java:152)
com.google.gerrit.server.account.IncludingGroupMembership.search(IncludingGroupMembership.java:115)
com.google.gerrit.server.account.IncludingGroupMembership.containsAnyOf(IncludingGroupMembership.java:93)
com.google.gerrit.server.account.IncludingGroupMembership.contains(IncludingGroupMembership.java:69)
com.google.gerrit.server.account.UniversalGroupBackend$UniversalGroupMembership.contains(UniversalGroupBackend.java:129)
com.google.gerrit.server.project.ProjectControl.match(ProjectControl.java:493)

Change the HashMap to a ConcurrentHashMap to handle concurrent access.

Change-Id: I36f654281b7a1d7126936d86d64e6827d8987577
Fix comment box font colors of dark CM themes

Bug: Issue 2964
Change-Id: Ie8b624b4201de696e6cfa282dca5f6000b1a901d
Allow to raise BooleanQuery limit in gerrit.config.

Raising the limit avoids failing a query BooleanQuery.TooManyClauses,
preventing users from seeing "400 cannot create query for index" error
in the "Conflicts with" part of the change screen.

Change-Id: Ie0bf14c4a3e6c4833c064f7ac822c08aa2aaffb8
Disable Gitweb for in-memory acceptance tests

When running any in-memory acceptance tests, if Gitweb is installed,
the tests were failing because the GitWebSerlvet initialization requires
gerrit.basePath.

Change-Id: Ia3286176c671f92366425f628a09a19caf90e23f
Fix ordering of 2.9.x releases in the release notes index.

Change-Id: Ifd835e4a344710d635caaedc323977d6fbfca8fd
Update replication plugin to latest revision

- Prevent creating repos on extra servers
- Remove unneeded 'throws NoSuchChangeException'

Change-Id: I8b1452e252fad58c41e6fe152f44aafc7537d4d7
Merge "Allow to raise BooleanQuery limit in gerrit.config." into stable-2.9
Merge "Update replication plugin to latest revision" into stable-2.9
Bump gwtorm to 1.14 - solves the primary key column order bug

As described in [1], due to a gwtorm bug the primary key column
order for compound keys was wrong for some Gerrit database tables.
This causes poor performance for those SQL queries which rely
on using a prefix of the primary key column sequence in their
WHERE conditions.

NOTE: this change solves the problem for new Gerrit sites.
For existing Gerrit sites, created using Gerrit 2.6 or newer
we will need a migration (in the master branch) and a site
program (in older releases) in order to fix the primary keys.

[1] https://gerrit-review.googlesource.com/61092

Change-Id: Ibfaeeb4b54468608b28c3352fe128ee148e3c0b9
Update EncryptedContactStore to not use deprecated/removed methods

The PGPEncryptedDataGenerator constructor and addMethod calls used in
EncryptedContactStore were deprecated in version 1.49 and removed in
version 1.51 of Bouncycastle.

Update the calls to use the recommended non-deprecated versions.

Change-Id: I134fd8c0b4538ae23a2c17dd0a632ddaff28aa3d
Bump Bouncycastle version to 1.51

This version fixed some bugs [1] and latest SSHD release that we need
has upgraded to this version as well: [2].

[1] https://www.bouncycastle.org/releasenotes.html
[2] https://issues.apache.org/jira/browse/SSHD-362

Change-Id: I84aee1e620091bcd49a1f0be47f4da011a8ff3ee
Bump SSHD Mina version to 2.0.8

SSHD version 0.13.0 uses this Mina version.

Change-Id: I7e27dce435764a19aa27b58ea619d063f640a8fb
SSHD: Update to 0.13.0

Long standing exhausting thread pool SSHD bug was apparently fixed
upstream [1].

All Gerrit releases since 2.8.5 are known to suffer from this problem
with the consequence that Gerrit must be restarted overnight.

[1] https://issues.apache.org/jira/browse/SSHD-348

Change-Id: Ic52277050aa0cd19b19531ee997d312fd7273ebc
SideBySide2: Correct placement of column margin bar

Some browsers (Chrome, Firefox) are now using non-integer font widths
for the fixed width text display from CM3. Chrome on Mac OS X is now
measuring 7.2 pixels per character.

Unfortunately this can only be discovered by measuring the width of an
element with more than 1 character in it.  CM3's defaultCharWidth()
function measures the width of a single "x" and assumes this is going
to be accurate.  Except the browser rounds down and returns 7.0, which
is 0.2 short for longer runs of text.

Measure a 100 character string in a span and take the average width of
these 100 characters to identify the real character width used for
text in a CM3 instance.  This is now coming in around 7.2 px, which
can be multipled out with the integral columns to get the margin bar
positioned at the desired location in source files.

The string length needs to be long enough that most browsers will show
evidence of fractional character widths.  100 is a good guess as some
coding standard conventions limit lines to 100 (or even 80),
suggesting no conforming code would even reach this length of 100.

If the margin was set at 100, and the measurement was taken for 100
but is still flawed, at worst the margin bar should position correctly
at 100.  It also gives about 2 decimal places of precision on the char
width, assuming fractional widths are being used by the browser.  This
may be fine for 100 character wide line lengths, any residual error
should be small enough to go unnoticed.

Issue: 2918
Change-Id: I37f328f1c5475f4aaa2ad1c90b6339fdc2c6ef5c
Inject InitStep members again before calling postRun.

InitStep instances are created before a site is initialized and the set
of injectable objects is quite small at that time. This also limits
what could be done from the postRun method, which is invoked after site
is initialized.

After the site is initialized a sysInjector is already available and
we could make use of it in order to perform optional injection and
provide the InitStep.postRun with additional useful objects. This way
the postRun can perform many more things than before.

To make use of the optional injection in an InitStep one would write
something like:

  public class MyInitStep implements InitStep {

    private final ConsoleUI ui;

    @Inject
    MyInitStep(ConsoleUI ui) {
      this.ui = ui;
    }

    @Override
    public void run() throws Exception {
      ...
    }

    @Inject(optional = true)
    void setGitRepositoryManager(GitRepositoryManager git) {
      gitManager = git;
    }

    @Override
    public void postRun() throws Exception {
      // make use of gitManager
    }
  }

Change-Id: Idfd04747f45db8c7e0aee892175245ccd280d5e0
Merge "Inject InitStep members again before calling postRun." into stable-2.9
Merge changes from topic 'sshd-upgrade' into stable-2.9

* changes:
  SSHD: Update to 0.13.0
  Bump SSHD Mina version to 2.0.8
  Bump Bouncycastle version to 1.51
  Update EncryptedContactStore to not use deprecated/removed methods
Bump version to 2.9.2

Change-Id: I017362b20aa53684fc46acdfed6d3162405dbbc2