VA: Use performValidation for IsCAAValid remote checks

[beautifulentropy]

• Remove undeployed feature flag MultiCAAFullResults
• Perform local CAA checks prior to initiating remote checks, instead of starting remote checks and proceeding to perform local checks.
• Remove VA.IsCAAValid specific remote validation logic, use VA.performRemoteOperation instead
• Refactor va.logRemoteResults to be easier to test and omit the RVA problem
• Drive-by fix: Calculate logEvent.Latency with va.clk.Since() instead of time.Since() like everything else in VA.performRemoteOperation

---

This change must be merged after #7847.

[github-actions]

@beautifulentropy, this PR appears to contain configuration and/or SQL schema changes. Please ensure that a corresponding deployment ticket has been filed with the new values.

[jsha]

This looks great. I love seeing performRemoteCAACheck and processRemoteCAAResults deleted in favor of using shared code.

It's a bummer to see performRemoteValidation, which was made so beautifully generic in #7847, wind up needing special-case code for CAA. I think we talked about the reasons on our call yesterday. Let me check my understanding:

• The current tests in TestMultiCAARechecking check that:
  • There is a log line detailing the remote differentials (logRemoteDifferentials JSON=, which is logged by logRemoteResults)
  • When a ProblemDetails is returned by any remote, it gets logged in performRemoteValidation (by comparison, the PerformValidation doesn't log ProblemDetails in performRemoteValidation, only RPC-level errors)
• Because these current tests actually test properties that are very similar to the properties we will be checking for MPIC, we want to preserve them so that we can see clearly in the MPIC-related diffs that the same tests pass the same sort of checks.
• Once the MPIC code lands we can remove the CAA-related special cases from performRemoteValidation?

Is that all sound correct?

The base branch was changed.

[beautifulentropy]

This looks great. I love seeing performRemoteCAACheck and processRemoteCAAResults deleted in favor of using shared code.

It's a bummer to see performRemoteValidation, which was made so beautifully generic in #7847, wind up needing special-case code for CAA. I think we talked about the reasons on our call yesterday. Let me check my understanding:

• The current tests in TestMultiCAARechecking check that:

  • There is a log line detailing the remote differentials (logRemoteDifferentials JSON=, which is logged by logRemoteResults)
  • When a ProblemDetails is returned by any remote, it gets logged in performRemoteValidation (by comparison, the PerformValidation doesn't log ProblemDetails in performRemoteValidation, only RPC-level errors)

• Because these current tests actually test properties that are very similar to the properties we will be checking for MPIC, we want to preserve them so that we can see clearly in the MPIC-related diffs that the same tests pass the same sort of checks.

• Once the MPIC code lands we can remove the CAA-related special cases from performRemoteValidation?

Is that all sound correct?

Yes, all of this is correct. I'd also like to add that we have not and never plan to turn EnforceMultiCAA on in staging or production. Thus these carve outs in performRemoteOperation will only be exercised in test.