VA: Only use `prob` to reflect problems outside our infrastructure

Lots of code in the VA package handles probs, often returning them when something has gone wrong. On the one hand, this makes sense: the ACME spec defines several problems that have to do with validation, and we want to ensure that we can properly store and return problems of the appropriate types when the client checks their authz state.

However, we also return lots of probs.ServerInternal when something has gone wrong in our own infrastructure, like a failed gRPC connection. This is bad, because it makes it very hard to tell the difference between problems that merely need to be stored and problems that are much worse.

As an example, see va.doRemoteOperation. It returns an MPIC summary and a problem, and often both are non-nil. Sometimes that problem is "some RVAs didn't see the right token", which is a simple validation failure. Sometimes that problem is "the result the RVA returned was malformed" or "we couldn't reach an RVA", which are also validation failures, but they're our fault, not the applicant's. And sometimes that problem is "we aren't even configured with enough RVAs to attempt MPIC", in which case the summary is nil.

We should ensure that all issues within our own infrastructure are returned as errors, and all mere validation issues are returned as problems. We can convert our own issues into problems at the boundary of the VA, for storage in the SA.

Start by tracing the VA package and va.doRemoteOperation, including how its MPIC summary and problem are consumed at the VA-to-SA boundary. Identify which outcomes are validation problems versus failures in Boulder’s infrastructure, and verify that storage receives converted problems only for the former while infrastructure failures remain errors.