Subscription errors get lost when merging schemas

[dh94]

I think this issue is since mergeSchemas was introduced,
when merging a schema that contains subscriptions the errors that are thrown from the reducers
are lost from the result

Intended outcome: subscription fields errors should be included after merging schemas as well

Actual outcome: errors are lost, for example
for the following subscription:

type TimeQuery {
    time: String
    throwError: Boolean
}

type Subscription {
    tellMeTime: TimeQuery
}

subscription {
  tellMeTime {
    time
    throwError
  }
}

when not using mergeSchema this is the subscription result:

{
    "type": "data",
    "id": "2",
    "payload": {
        "errors": [{
            "message": "",
            "locations": [{
                "line": 4,
                "column": 5
            }],
            "path": ["tellMeTime", "throwError"]
        }],
        "data": {
            "tellMeTime": {
                "time": "11:22:29",
                "throwError": null
            }
        }
    }
}

and when I am using mergeSchemas this is the subscription result

{
    "type:" "data",
    "id": "2",
    "payload": {
        "data": {
            "tellMeTime": {
                "time": "11:09:02",
                "throwError": null
            }
        }
    }
}

How to reproduce the issue:
I created a WebSocket server like
https://www.apollographql.com/docs/graphql-subscriptions/setup.html#subscription-server
and gave it the following schema:
https://gist.github.com/dh94/1dec5c54ecdb9c20e52985fff4ccaa6b#file-merged-schema-ts

packages version used:

    "apollo-server-express": "^1.3.6",
    "express": "^4.16.2",
    "graphql": "^0.13.1",
    "graphql-subscriptions": "^0.5.8",
    "graphql-tools": "^3.0.1",
    "subscriptions-transport-ws": "^0.9.9",
    "typescript": "^2.7.2"

• has-reproduction
• feature
• docs
• blocking
• good first issue

[dh94]

from what i gathered it looks directly related to this issue,
#780
i'll try to create a pull request handling this

[hwillson]

Closing as this was likely addressed by #795. Thanks!