chore: run ingress filter on latest certified state

[mraszyk]

This PR makes the ingress filter run on the latest certified state (instead of the latest - potentially uncertified - state).

Motivation

This change fixes the following inconsistency for non-replicated execution:

• A non-replicated query call uses the latest certified state (necessary because a certificate is provided to execution).
• A canister http outcall transform uses the latest certified state.
• A canister ingress filter uses the latest (potentially uncertified) state!

In the last two cases, no certificate is provided to execution and thus both certified and uncertified states could be used technically:

• the latest certified state is more "trustworthy" and less prone to divergence;
• the latest (potentially uncertified) state is more "recent".

Since it is not clear why a more "recent" uncertified state is more appropriate, we switch to using the latest certified state in all cases.

Changes to Tests

StateMachine/PocketIC tests execute an empty round at the very beginning to always have a certified state available. This makes the first checkpoint be produced earlier and changes the randomness delivered to canisters in such tests (its seed is derived from the round number which increases by one). There's no change in round timestamps.

[github-actions]

This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):

1. Update unreleased_changelog.md (if there are behavior changes, even if they are
   non-breaking).

2. Are there BREAKING changes?

3. Is a data migration needed?

4. Security review?

How to Satisfy This Automatic Review

1. Go to the bottom of the pull request page.

2. Look for where it says this bot is requesting changes.

3. Click the three dots to the right.

4. Select "Dismiss review".

5. In the text entry box, respond to each of the numbered items in the previous
   section, declare one of the following:

• Done.

• $REASON_WHY_NO_NEED. E.g. for unreleased_changelog.md, "No
  canister behavior changes.", or for item 2, "Existing APIs
  behave as before.".

Brief Guide to "Externally Visible" Changes

"Externally visible behavior change" is very often due to some NEW canister API.

Changes to EXISTING APIs are more likely to be "breaking".

If these changes are breaking, make sure that clients know how to migrate, how to
maintain their continuity of operations.

If your changes are behind a feature flag, then, do NOT add entrie(s) to
unreleased_changelog.md in this PR! But rather, add entrie(s) later, in the PR
that enables these changes in production.

Reference(s)

For a more comprehensive checklist, see here.

GOVERNANCE_CHECKLIST_REMINDER_DEDUP

No canister behavior changes.

[kpop-dfinity]

LGTM