regression in http status setting for certain errors (v3 to v4)
### Issue Description

We are in the process of upgrading our system from `v3` to `v4` and see a regression in several unit tests for HTTP status codes of invalid inputs. The particular error is of the form:

```
Variable "$foo" of required type "ID!" was not provided
```

I've traced these calls into `requestPipeline.ts` and do not see any mechanism for setting HTTP status after the pipeline reaches a specific point. We have other test cases that did not regress; all of these were caught earlier in the pipeline (e.g. [here](https://github.com/apollographql/apollo-server/blob/main/packages/server/src/requestPipeline.ts#L217)).

The problematic behaviors occurs on lines [474-477](https://github.com/apollographql/apollo-server/blob/%40apollo/server%404.5.0/packages/server/src/requestPipeline.ts#L474-L477):

```ts
const { formattedErrors, httpFromErrors } = resultErrors
    ? formatErrors(resultErrors)
    : { formattedErrors: undefined, httpFromErrors: newHTTPGraphQLHead() };
mergeHTTPGraphQLHead(requestContext.response.http, httpFromErrors);
```

If there are errors (eg. if resultErrors exists), the `formatErrors` [function](https://github.com/apollographql/apollo-server/blob/main/packages/server/src/requestPipeline.ts#L663-L672) delegates to the `normalizeAndFormatErrors` [function](https://github.com/apollographql/apollo-server/blob/main/packages/server/src/errorNormalize.ts#L21-L56), which always creates a new instance for `httpFromErrors`.

Subsequently the `mergeHTTPGraphQLHead` [function](https://github.com/apollographql/apollo-server/blob/main/packages/server/src/runHttpQuery.ts#L403-L417) only sets the `target.status` to a non-200 HTTP code if this `httpFromErrors` value defines a `status`, which it does not because it is a fresh instance and takes no input from the `resultErrors`.

I have not taken the time to dig into the older software, but this seems like an obvious regression; either this kind of error should be caught earlier in the pipeline (where it can be handled differently) or this part of the pipeline should be able to set the HTTP status based on the error content.

### Link to Reproduction

n/a

### Reproduction Steps

Our setup is: `application` => `internal framework` => `@nestjs/graphql` => `@nestjs/apollo` => `@apollo/server`.

I get the value and importance of a reproducible test case; I also estimate that it would take several days to strip down this flow into something that neither leaked internal systems and directly used apollo (vs `@nestjs`). I'm hopefully that my line-by-line breakdown of the issue suffices; I doubt we can take the time to produce a palatable reproduction. 