Port cards API

[onecrayon]

This is a high priority because it is necessary to start work on the front-end application. This depends on #7 since we need to distinguish between legacy and Reborn cards.

Card create POST /v2/cards

• [x] Create input schema and validation
• [x] Add logic for calculating cost weight
• [x] Convert various cost options into flags, formatted lists, etc.
• [x] Add logic to automatically create a release if it doesn't already exist, since we only need the name nowadays
• [x] Figure out how to handle conjurations, since they may or may not exist yet
• [x] Construct card JSON and save it and all generated data to the database
• [x] Parse conjurations and add to JSON, and also to the relationship table
• [x] Full test coverage
  • [x] Figure out if attack/life/recover values are all getting converted to integers in the JSON (need to ensure they are strings, unless it's literally just an integer)

Listing endpoint GET /v2/cards

• [x] Port listing logic defined here using an endpoint like GET /cards: https://github.com/onecrayon/ashes.live/blob/master/app/views/api/cards.py#L17
  • [x] Exclude legacy v1 cards by default
  • [x] Support query string ?show_legacy=true.
  • [x] NEW: Implement pagination logic
  • [x] Convert Card.json column to JSONB
  • [x] Ensure that we have the proper indexes to support all filtration techniques from the old site
  • [x] Implement full text search (need to research how best to do this in Postgres)
  • [x] Implement card output schema
  • [x] Migrate dice filtration logic into the view out of the model
  • [x] Test all filters by hand (not sure they're actually working right, based on the old site)
  • [x] Ensure all filters are properly documented in OpenAPI spec
  • [x] Figure out how to handle conjurations in the card JSON output
    • [x] Name + stub? (would require data migration)
    • [x] Should we traverse the full tree? Not doing this for now
• [x] Full test coverage
  • [x] Come up with a way to test filtration logic in a performant way (this is going to be tricky)
• [x] Add data migration to strip out thumbnails and images from card JSON, and convert text into a string instead of a bunch of nested arrays
  • [x] Add is_legacy flag to the JSON object? Would be useful on the front-end, but maybe only include on legacy cards
  • [x] Test the initial data SQL against the new JSONB column, and update to ensure it doesn't include thumbnails or IDs and has string text

Open questions

• [x] Should we switch to using card stubs for Phoenixborn instead of their textual name? Requires data migration, if so. Not worth it.
• [x] Should we return Ashes 500 data for legacy requests? Went with "no" because the 500 listing won't be a thing anymore

Card details GET /v2/cards/{stub}

Card detail endpoint will be used for tooltips around the front-end, so it needs to be fast. Tooltips need full card data and conjuration lists. For now, the JSON should mainly just be what's already stored in the database, although I may revisit the storage for cards because I think it might be a bit over-engineered.

• [x] Create individual card view endpoint like GET /cards/{stub}
  • [x] Endpoint should return primary card JSON for Reborn cards, including a basic list of conjurations (conjurations should be name and stub; don't need or want the full object. Need to keep database queries down, so be careful with relationships!)
  • [x] Support is_legacy flag to show 1.0 vs. Reborn cards
• [x] Full test coverage