Backport error/exception handling improvements

Cherry-picking compatible fixes and features from the master branch for v1.2.0:

• GraphQL parse errors should be much easier to read now.
• Exceptions in a single field should no longer fail the entire request, instead it'll accumulate multiple errors and return them along with whatever partial results it was able to retrieve in the data member.
• Refactored the operation definition visitors to share more code and expose a public method findOperationDefinition to figure out the operation type.

Added support for matching subscription arguments

I need to make a couple of breaking API changes to fix the next set of bugs, so I'm separating the latest changes in a v1.1.x branch. The next release should be v2.0.0, unless I need to make any bug fixes in v1.x.x before then.

The new feature that bumped this up from the v1.0.x series is support for subscription arguments and filters based on those arguments. I also fixed a couple of bugs in response::Value which didn't require breaking changes to the API.

Bug fixes for enum values, interfaces, and JSON parsing

I found and fixed several bugs with a private schema I started working on that includes enum values as resolver parameters, types with multiple interface implementations, and nested JSON objects in some of the test data.

Bug fix in schemagen list value default value parsing

The same bug I fixed in v1.0.1 also exists in the schemagen list value visitor in DefaultValueVisitor.

Bug fix in list value parsing

There was a bug in the GraphQL list value parser which expected an intermediate node in the parse tree between the list and the items in the list. Passing list values as variables works around the bug, but if you build a list in the GraphQL query (including inserting a variable value into a list) it would dereference an out of bounds vector element on an empty vector.

1.0.0 Release

All planned features and testing are done, so let's call it complete. 💯

I built it into an Electron app with a Node native module and I got GraphiQL working against that, which uncovered some gaps in the Introspection support. I plan on publishing the native module and the GraphiQL app which consumes it as samples under my own account rather than trying to integrate them as complete projects into this one. Relevant code snippets might make their way into the documentation.

I also added runtime @directive support. You can declare custom directives in the schema and they will be included in the Introspection. If you include directives in your queries at runtime, they will be passed to each of the getField interface accessors in a response::Value 2-level map.

To support passing directives and adding future parameters, I defined a parameter block struct service::FieldParams. The signature of the generated interfaces should not need to change again just to support passing new contextual or environmental parameters into them, which will make it easier to perform non-breaking minor-version updates in the future.

Many new features!

This release incorporates several large refactors since v0.6. It's much closer to a v1.0 release than before, but there are still a couple of Issues to work through before jumping to v1.0.

Highlights include:

• Better CMake configuration for inclusion in other projects
• Async support using std::future<> and service::RequestState
• JSON-agnostic GraphQL responses. It's still using RapidJSON for JSON serialization by default, but now it's isolated in a single file which you can replace if you want to link with something else.
• GraphQL subscription support (subscribe/unsubscribe/deliver)

The downside is that if you have a lot of custom code in your interface implementations or callers, the signatures of most of these methods changed quite a bit, particularly for the async support. I don't anticipate needing to break the interface again between now and v1.0.

User Defined Literals and performance improvements

• I added a C++ string UDL so you can parse a hard-coded GraphQL query or schema with "..."_graphql, much like the graphql function in Relay which instructs the relay-compiler to preprocess queries embedded in JS/JSX (or TS/TSX for TypeScript).
• I made some improvements to the tests to cache more between tests in the test class/fixture so there's less work in the per-test Setup/Teardown.
• The RapidJSON calls are optimized to avoid excessive memory copies between separate documents at runtime in the service. Pretty much all of the rapidjson::Value objects included in the results document should be constructed in place using the target document's own allocator.

CMake cleanup

Making the build compatible with package managers such as vcpkg without requiring additional patches.

Replacing cpprestsdk with RapidJSON

This release doesn't have any runtime dependencies on building other projects. All of the dependencies are header-only libraries now.