pull: fix post-pull common computation

Before that changes, pulled revision that happend to be already known locally
(so, not actually added) was not taken into account when computing the new
common set between local and remote.

It appears that we already know the heads of the pulled set. It is in the
`rheads` variable, so we are just using it and everything is works fine.

We are dropping the, now useless, computation of `added` set in the process.
push: more robust check for bundle fast path

When all changesets in the local repo are either being pushed or remotly known,
we can take a fast path when bundling changeset because we are certain all local
deltas are computed againts base known remotely.

So we have a check to detect this situation, when we did a bare push and nothing
was excluded.

In a coming refactoring, the discovery will run on filtered view and the content
of `outgoing.excluded` will just include unserved (secret) changeset not filtered by the
repoview used to call push (usually "visible"). So we need to check if there is
both no excluded changeset and nothing filtered by the current repoview.
pull: run findcommon incoming on unfiltered repo

The discovery is not yet ready for filtered repo. Pull was using filtered for
its discovery which is wrong. It worked by dumb luck because discovery mainly
use funtion that does not respect the filtering.

Trying to makes discovery work on filtered repo revealed this bug.
discovery: make revlogdag work on filtered repo

The revlogdag class is a core part of discovery. We need its initialisation to
exclude revision filtered out.
discovery: enforce filtering into revlogbaseddag._internalizeall

One more step toward discovery running on filtered repo.
discovery: stop using nodemap for membership testing

Nodemap is not aware of filtering so we need to ask the changelog itself if a
node is known. This is probably a bit slower but such check does not dominated
discovery time. This is necessary if we want to run discovery on filtered repo.