OpenAPI revisions for compatibility with Fern SDK generator

[nikochiko]

Change Summary

• auth
  • new APIAuth class that inherits from fastapi.security.base.SecurityBase (refactored into this from api_auth_header to output OpenAPI with bearer scheme)
  • rename auth_keyword to auth_scheme
• method names with fern-specific openapi attributes
  • add get_openapi_extra classmethod to BasePage
  • add sdk_method_name class attribute to BasePage
  • x-fern-ignore API endpoints that shouldn't be present in SDK
• Model classes
  • Rename Text2ImgModels to TextToImageModels for parity with SDK names
  • Rename Img2ImgModels to ImageToImageModels for parity with SDK names
  • Rename LipsyncModel to LipsyncModels (plural) for consistency with rest of model classes
• GooeyEnum
  • add api_enum class property for GooeyEnum that creates a dynamic enum mapping from api_value->api_value (default, name->name)
  • remove api_choices in favor of api_enum
  • make use of GooeyEnum for
    • AnimationModels
    • AsrModels
    • TextToImageModels
    • ImageToImageModels
    • SegmentationModels
    • UpscalerModels
    • ControlNetModels
    • AsrOutputFormat
    • CitationStyles
    • Schedulers
    • TextToSpeechProviders
    • TextToAudioModels
    • CombineDocumentChainType
    • SerpSearchType
    • SerpSearchLocations

Q/A checklist

• If you add new dependencies, did you update the lock file?

poetry lock --no-update

• Run tests

ulimit -n unlimited && ./scripts/run-tests.sh

• Do a self code review of the changes - Read the diff at least twice.
• Carefully think about the stuff that might break because of this change - this sounds obvious but it's easy to forget to do "Go to references" on each function you're changing and see if it's used in a way you didn't expect.
• The relevant pages still run when you press submit
• The API for those pages still work (API tab)
• The public API interface doesn't change if you didn't want it to (check API tab > docs page)
• Do your UI changes (if applicable) look acceptable on mobile?
• Ensure you have not regressed the import time unless you have a good reason to do so.
  You can visualize this using tuna:

python3 -X importtime -c 'import server' 2> out.log && tuna out.log

To measure import time for a specific library:

$ time python -c 'import pandas'

________________________________________________________
Executed in    1.15 secs    fish           external
   usr time    2.22 secs   86.00 micros    2.22 secs
   sys time    0.72 secs  613.00 micros    0.72 secs

To reduce import times, import libraries that take a long time inside the functions that use them instead of at the top of the file:

def my_function():
    import pandas as pd
    ...

Legal Boilerplate

Look, I get it. The entity doing business as “Gooey.AI” and/or “Dara.network” was incorporated in the State of Delaware in 2020 as Dara Network Inc. and is gonna need some rights from me in order to utilize my contributions in this PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Dara Network Inc can use, modify, copy, and redistribute my contributions, under its choice of terms.

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1208315549936081
  • https://app.asana.com/0/0/1207921877486111

[devxpy]

do we really need this huge refactor of all enums?

[devxpy]

in any case if this can be broken up between the auth header and the enum that would be greatly appreciated

[nikochiko]

do we really need this huge refactor of all enums?

I used GooeyEnum where we were already using Enums or TextChoices per #393. That was an easier change and consistent with this discussion.

Where it was something else, I have used x-fern-type-name to not make new Enums.

[devxpy]

do we really need this huge refactor of all enums?

I used GooeyEnum where we were already using Enums or TextChoices per #393. That was an easier change and consistent with this discussion.

Where it was something else, I have used x-fern-type-name to not make new Enums.

Do we need the enum for fern to generate the literal | str type annotation? The enum refactor is nice but i think it would need a lot of testing to pass the review

[nikochiko]

By default, Fern will generate types like

CompareLLMSelectedModelsItem = typing.Union[typing.Literal[...], typing.Any]

Giving an Enum type lets us customize this name because fastapi will generate an OpenAPI component with the name inferred from the Enum's name.

By default, Literals will create a new OpenAPI Enum type for each input, and each will have its own different name.

[nikochiko]

Separated into this and #465

[nikochiko]

The enum refactor is nice but i think it would need a lot of testing to pass the review

I have tested all the affected recipes in this PR - the UX names, API names, and their use in run & run_v2 - with different models and settings.

The nice thing with the refactor is that it doesn't affect how the value is stored in state, or passed down to the run method of each recipe. So that logic doesn't need any changes (I have still tested, and fixed where this wasn't the case).
The automated tests already guarantee that all pages load with 200, sane_defaults work as before. We can continue testing like before manually after deployment, and also revert easily in case anything is breaking (because no migrations).