Feature/graphql chapter pages mutation handle downloaded chapters

[schroda]

No description provided.

[Syer10]

I would prefer to avoid getChapterDownloadReady unless its optimized, it does a lot of unneeded database queries

[schroda]

I updated ChapterForDownload to work with just the chapterId being passed.
should get rid of the last duplicated transactions (chapter, manga), otherwise, I don't really see any unneeded queries.

I think it would be best to decouple logic like this. then you have one place which handles e.g. in this case getting the chapter pages.
In this case it matters for the rest api and graphql, but in other cases we might need the logic "internally" somewhere (not api relevant), e.g. the updater/downloader.
currently these places use the "old" (?) logic that was also used by the rest api and graphql does its own stuff.
which now causes changes to have to be done in two different places

[Syer10]

The goal is to have GraphQL be as optimized as possible, while sharing code between it and the old Rest API is fine, its secondary since we don't plan to improve the Rest API in the future. When we drop the REST api we will drop a bunch of old code as well, anything that is not used by the GraphQL api will be removed, allowing us to further optimize the GraphQL api.