Use _bramble__typename alias for bramble injected __typename

[lucianjon]

Following on from the work in #94. With that change in place there are certain aliases that are reserved for bramble's internal use, this changes the __typename alias to be _bramble__typename.

Rationale

• create a pattern of reserved aliases starting with _bramble
• reduce the chance of someone wanting to genuinely use the __typename alias for different purposes being unable to do so
• because of the point above there should generally be no confusion about whether the client requested the __typename field or bramble injected it

As a side note, any bramble injected fields (that were also not explicitly requested) are automatically omitted from the final response. This is because the response formatting uses the client's selection set to decide what goes into the response. Also, in the future we could consider failing queries that include the reserved aliases entirely.

New Test Suite

On top of the above changes there is a new minimal test suite, designed to test much more of bramble's internals in one go. The main difference between these tests and the tests in execution_test.go is the new suite will bring up and query real graphql servers. The tests are in server_test.go and the test server implementations in a package testsrv.

Given these servers are not mocked out there is a high overhead to new schemas and changes to what they now have. So the tests against them are minimal for now.

The biggest benefit of these tests is testing the plan against spec compliant graphql servers. The existing tests rely on manually crafted JSON to use as graphql responses and so don't test the plan itself but rather what the person writing the tests thinks it should be. Manually writing JSON is also fairly error prone and can cause frustrating test failures.

They also give us a quick end to end test that makes sure bramble can fetch schemas of downstream services, merge these and then run queries on the merged schema.

[pkqk]

Good idea with the test suite, might be able to make the test servers skip the network stack if we abstract out the Service like we've been talking about for v2.

[gmac]

High-five on the end-to-end tests! I was nervous about those being missing while updating test fixtures. Nice work!

[lucianjon]

Thanks, yeah definitely more comfortable making changes in the planner/execution pipeline with real servers to check against