Modpack backend changes

[rhit-zhangl8]

Added install grid calculation for Windows, Windows server, and Linux server, as well as tests.

[codecov]

Codecov Report

❌ Patch coverage is 49.10180% with 170 lines in your changes missing coverage. Please review.
✅ Project coverage is 41.35%. Comparing base (25e7660) to head (eff5e1c).
⚠️ Report is 59 commits behind head on feat/modpacks.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
gql/resolver_modpacks.go	49.25%	124 Missing and 12 partials ⚠️
gql/directive.go	6.25%	15 Missing ⚠️
db/user.go	0.00%	13 Missing ⚠️
conversion/ent_to_graphql.go	79.31%	4 Missing and 2 partials ⚠️

Additional details and impacted files

@@                Coverage Diff                @@
##           feat/modpacks     #136      +/-   ##
=================================================
+ Coverage          41.18%   41.35%   +0.16%     
=================================================
  Files                135      113      -22     
  Lines               8274     8137     -137     
=================================================
- Hits                3408     3365      -43     
+ Misses              4422     4316     -106     
- Partials             444      456      +12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rhit-mooretj]

Do we think this would make sense to run on creation of a modpack release to store the values? Modpacks have target fields right now that are unused, and I wonder if upon a call of "createmodpackrelease" the resolver calls this function instead of it being outward facing for the frontend to run this over and over again. If so, we should remove the targets field ever being required for a SQL call to clean it up before we implement it on the frontend. What do you think Rob?

The code itself looks good to me, so I have no issues with that just maybe a slight tweak on the usecase in practice.

[budak7273]

Partial review, haven't made it all the way through yet

[budak7273]

Do we think this would make sense to run on creation of a modpack release to store the values? <...>

I think we discussed this on the discord, is the comment's question still relevant? Since modpack releases are immutable I think it makes sense to cache the target support on them yeah.

[rhit-mooretj]

Do we think this would make sense to run on creation of a modpack release to store the values? <...>

I think we discussed this on the discord, is the comment's question still relevant? Since modpack releases are immutable I think it makes sense to cache the target support on them yeah.

This is no longer relevant. Each release stores targets that are calculated upon previewing a release, and also stored on modpack creation. The query to get targets is through GetModpacks, as you'll get info on the releases

[budak7273]

Merging this now since it will get reviewed in #125's PR anyways so there are less things floating around