The branchmap code is actually quite expensive (O(changelog)). So let's try
to avoid them as much as possible.
First, reading or writing on-disk caches are unnecessary since even with the
on-disk cache, it still has to pay O(changelog) headrevs cost to
incrementally update the cache, which is the same cost of rebuilding the
cache from memory.
Secondly, repo.branchmap() calls update unconditionally so the update
function should be smart to not update unnecessarily. That's the validfor
Thirdly, repo.branchmap() calls branchmap.updatecache which constructs
the "served", "immutable", "base" repoviews as an attempt to "incrementally"
build the branch cache for the "visible" repoview. There is no need to have
that many repoviews in this case. Therefore branchmap.updatecache is
replaced to a simplified version that does not construct other repoviews.
Note: there is a simple cache in index.headrevs() but that cache gets
invalidated if filteredrevs has a different address - that means different
repoviews will not benefit from index.headrevs() cache if they pass
different filteredrevs objects.
The change is gated by a new config option perftweaks.disablebranchcache2
so we can rollback if anything went wrong.