indexer management client with db connection and cost server

[hopeyen]

Resolves #19 and #3
some quick notes

• Simple indexer management client is now tracking both NetworkSubgraph and postgres connection
• Define cost model schema and resolvers with postgres and graphQL types, with global cost model fallback when specific deployments are queried
• No migration in indexer service; indexer agent is solely responsible for database management.

[github-actions]

Pull Request Test Coverage Report for Build 6053871226

• 0 of 226 (0.0%) changed or added relevant lines in 8 files are covered.
• 3 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-3.8%) to 37.705%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
service/src/common/indexer_error.rs	0	2	0.0%
service/src/server/mod.rs	0	2	0.0%
service/src/main.rs	0	10	0.0%
service/src/server/routes/cost.rs	0	10	0.0%
service/src/common/indexer_management_client/mod.rs	0	12	0.0%
service/src/common/database.rs	0	21	0.0%
service/src/common/indexer_management_client/schema.rs	0	26	0.0%
service/src/common/indexer_management_client/resolver.rs	0	143	0.0%

Files with Coverage Reduction	New Missed Lines	%
service/src/common/database.rs	1	0.0%
service/src/metrics/mod.rs	1	0.0%
service/src/util.rs	1	17.35%

Totals
Change from base Build 6029635279:	-3.8%
Covered Lines:	874
Relevant Lines:	2318

---

💛 - Coveralls

[aasseman]

LGTM overall, just a few little things (see code comments).

Things that could be explored later:

• It'd be nice to have some tests on the graphql server, with request/response test vectors.
• Perhaps some migrations could be added only for the purposes of testing. I couldn't build on my machine (sqlx complaining) and had to run a PG instance and create the table myself. Though I'm confused why the CI didn't run into that problem.
• Related to the point above, we could set-up the CI such that there is a PG instance available, to avoid ignoring all the tests using sqlx.

[hopeyen]

Thanks for the review @aasseman !
I've addressed the comments and regarding to things for later

tests on the graphql server, with request/response test vectors.

Agreed and added an item on #15

Perhaps some migrations could be added only for the purposes of testing. I couldn't build on my machine (sqlx complaining) and had to run a PG instance and create the table myself. Though I'm confused why the CI didn't run into that problem.

Would it be because those tests had [ignore] and cargo llvm-cov test doesn't test the ignored?
I've added a migrations folder for you to try out if you would like

Related to the point above, we could set-up the CI such that there is a PG instance available, to avoid ignoring all the tests using sqlx.

Agreed as well, it would just need to run sqlx migrate run once the instance is available

[aasseman]

One last thing, perhaps adding a migrations/README.md that explains that the migrations are there only for testing?

[aasseman]

FYI #44

[hopeyen]

adding a migrations/README.md that explains that the migrations are there only for testing

Good idea! added in 478182b

[aasseman]