The current branch cache is hyper-optimized to support exactly two
types of branch queries: all branches for a project, or unprotected
branches for a project. GitHub provides another axis: "locked"
branches. Cconceivably, other code review systems could as well, and
there may be even more axes in the future.
In order to support locked branches in a future change, we must first
refactor the branch cache to support more than two queries. This
change implements that with the following scheme:
The branch cache will be a dictionary of project_name -> ProjectInfo,
and ProjectInfo will hold general information about the project such
as supported merge modes and default branch, as well as another
dictionary branch_name -> BranchInfo. The BranchInfo record will hold
boolean flags indicating whether the branch is protected or locked.
Additionally, the project_info record will hold a set of which queries
for these flags have been performed and whether they were successful
or not. This allows us to determine whether the branch_info flags
are valid or not. For example, if we have only performed a query to
get all the branches, and a caller requests a list of protected
branches, we know that the BranchInfo.protected bool is not valid,
so we return a LookupEerror to the caller which will trigger another
query to get the protected branch list which will then be used to
update the branch cache, setting the protected bool to true where
appropriate on existing BranchInfo objects and setting the protected
query flag on ProjectInfo. The result matches the current behavior,
but is extensible to support more flags.
In order to minimize the size of the branch cache in ZooKeeper, the
BranchInfo object is serialized as a simple integer with a bitmap of
the associated booleans. Likewise, the several queries are stored in
the serialized ProjectInfo as two bitmaps (one for success, and one
for failed).
This change stubs out the "locked" flag and query in some places, just
to demonstrate sufficiency for future use, but it does not implement
support for locked branches yet. A future change will do that.
As long as we don't actually add any locked branches, we can still
serialize to the old branch cache data structure, so this change does
so to enable rolling upgrades. Tests of the upgrade path and
continued operation on only the old data path are included.
Change-Id: I8841e675295f15e5d6dd004f9e34836b8bbbdb63
7741fc923c