v1.18: replay: do not early return when marking slots duplicate confirmed (backport of #2700)

[mergify]

Problem

When processing duplicate confirmed slots from gossip or replay we early return if we have already duplicate confirmed this slot.

This can cause the following situation:

• Slot S is DC through gossip and marked as valid in fork choice.
• Later replay of a slot S + 2 indicates that S and S + 1 are DC.
• We see that we've already marked S as DC through gossip, so we early exit.
• S + 1 is never marked as valid in fork choice.

And vice versa if S is first marked DC through replay.

Summary of Changes

continue instead so we can process any new slots later in the queue.

---

This is an automatic backport of pull request #2700 done by [Mergify](https://mergify.com).

[mergify]

Cherry-pick of 1444baa has failed:

On branch mergify/bp/v1.18/pr-2700
Your branch is up to date with 'origin/v1.18'.

You are currently cherry-picking commit 1444baa426.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   core/src/replay_stage.rs

no changes added to commit (use "git add" and/or "git commit -a")

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[AshwinSekar]

This change has been backported to 2.0, however I believe it should also be backported to 1.18 in order to cover our bases for mainnet.

It changes 2 early returns to continues and adds 2 tests.

[steviez]

Conflict resolution looks good, but was also only in the unit tests