When different LLB vertexes (eg. parallel requests referencing
local sources from different sessions) generate same cache keys
during solve they are merged together into a single operation.

Currently, when this happened the progress for the vertex that
was dropped got lost. This fixes this case by adding the
progressWriter of the redirected vertex as a target to the
source one.

This should also work with multiple levels of merged edges,
just multiple nested multiwriters as well.

Signed-off-by: Tonis Tiigi <[email protected]>

Before this, it was possible for an edge merge to happen to a target
edge/state that is no longer in the actives map, e.g.
1. Job A solves some edges
2. Job B solves some edges that get merged with job A's edges
3. Job A is discarded
4. Job C solves some edges that get merged with job B's edges, which
   recursively end up merging to job A's, which no longer exist in the
   actives map.

While this doesn't always result in an error, given the right state and
order of operations this can result in `getState` or `getEdge` being
called on the "stale" edges that are inactive and an error. E.g. if a
stale dep transitions from desired state `cache-fast` to `cache-slow`,
the slow cache logic will call `getState` on it and return a `compute
cache` error.

I also *suspect* this is the same root cause behind `inconsistent graph
state` errors still seen occasionally, but have not repro'd that error
locally so can't be 100% sure yet.

The fix here updates `state.setEdge` to register all the jobs in the
source edge's state with the target edge's state. This works out
because:
1. edges that are the target of a merge will not have their state
   removed from the actives map if only the original job creating them
   is discarded
1. those edges are still removed eventually, but only when all jobs
   referencing them (now including jobs referencing them via edge
   merges) are discarded

Signed-off-by: Erik Sipsma <[email protected]>

Signed-off-by: Erik Sipsma <[email protected]>