feat: limit functions exposed in indexing status API

[hopeyen]

limit indexing status to serve supported root fields: indexingStatuses, publicProofsOfIndexing, entityChangesInBlock, blockData, cachedEthereumCalls, subgraphFeatures, apiVersions

So queries with root fields like indexingStatusForCurrentVersion, indexingStatusForPendingVersion, indexingStatusesForSubgraphName, ... should fail with bad request with a hint on the unsupported fields

Using Regex is brutal but get the job done while I didn't find similar functions in graphql crates like async-graphql and graphql-parser (also searched in graphql-tools-rs maintained by the guild.

Resolve #6

[github-actions]

Pull Request Test Coverage Report for Build 6332462657

• 71 of 85 (83.53%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+1.3%) to 46.49%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
common/src/graphql.rs	71	72	98.61%
service/src/server/routes/status.rs	0	13	0.0%

Totals
Change from base Build 6331848844:	1.3%
Covered Lines:	1265
Relevant Lines:	2721

---

💛 - Coveralls

[aasseman]

Simple and effective solution.

I think graphql_parser could have worked, but it would have been up to you to write a graph visitor to look for all the fields of the generated AST. More complex to write though, and probably worth it only if there's a need for a fancier GQL manipulations.

[hopeyen]

@aasseman Thank you for the review! I've updated to use lazy_static.

I think graphql_parser could have worked, but it would have been up to you to write a graph visitor to look for all the fields of the generated AST

I agree, was well on my way in handling different GraphQL executions with graphql_parser and wanted to use it for a better error messages, but became complicated with the nested types and enums. perhaps we can submit a feature request instead of making it ourselves

[aasseman]