Add Foreign Addon Imps feature: addon implemenations as external packages

[chiku-samugari]

Purpose

Introduce Foreign Addon Imps that enables third-party developers to create addon implemenations not built in to the gravyvalet codebase.

Changes

• Introduce AddonImpRegistry class, the dynamic registry of the addon imps in use.
  • The Addon implementation list on the External Service creation page is load dynamically.
• Allow to use addon implementations that is not built in to the gravyvalet codebase.
  • Foreign Addon Imps. Explained in FOREIGN_ADDON_IMP_DEVELOPMENT.md.
• All the addon imps, including built-in ones, needs to be registered to the newly introduced configuration ADDON_IMPS.
• Update README.md by adding how to use foreign addon imps.
• Add a document, FOREIGN_ADDON_IMP_DEVELOPMENT.md, that explains how to create foreign addon imps.
• Fix a few typos in comments
• Eliminate None type from enum_*_fields of GravyvaletModelAdmin

Side Effects

• Breaking Change: The icon_name of addon_services_externalservice table field type change requires database migration (0017_change_icon_name_to_charfield.py)
• Settings Update: All addon imps (both built-in and foreign) needs to be registered to the new ADDON_IMPS setting in app/settings.py

API Documentation

No changes to external API endpoints.

Internal API for addon imp registration has been replaced by AddonImpRegistry:

• register_addon_imps() - Discovers and registers foreign addon imps
• get_imp_by_name(), get_imp_by_number(), get_imp_name(), get_imp_number() - addon implementations lookup and reverse lookup

Foreign Addon Imp framework that supports third-party addon implementations is introduced:

• ForeignAddonImpConfig interface for creating Foreign Addon Imps
• Each Foreign Addon Imp can offer icons

QE Notes

• Verify built-in addon imps (Dropbox, Google Drive, etc.) continue to function normally
• Ensure admin interface properly displays all registered addon imps

CE Notes

• Run migration 0017_change_icon_name_to_charfield before deployment
• Foreign Addon Imps must be installed as Python packages and must be added to INSTALLED_APPS
• Each addon imp requires a unique ID number in ADDON_IMPS setting

[chiku-samugari]

Hi. I have just realized that the develop has moved ahead. Please let me know if you would like me to refresh (or rebase) this PR. Also, the GitHub Actions for this PR are currently awaiting maintainer approval, so checks have not run yet. Once approved, I will address any issues promptly. Thanks!

[brianjgeiger]

Quick drive-by, saw a typo.

[chiku-samugari]

Quick drive-by, saw a typo.

Thank you for catching that typo. My apologies for the oversight.

[futa-ikeda]

@chiku-samugari It looks like there are some merge conflicts that should be addressed here. Someone should be reviewing this PR shortly, as well

[chiku-samugari]

@futa-ikeda Thanks, I will work on merge conflicts. But the code base grows a lot since the PR was opened and it is better to check for necessary follow-up changes caused by this PR. I will work on this aspect too.

[chiku-samugari]

@futa-ikeda @brianjgeiger I have rebased onto develop branch and resolved the conflicts. I also applied some follow-up adjustments to align with recent changes. This should be ready for review now.

[sh-andriy]

Overall: Good implementation with a few concerns

This is a solid feature that opens the addon system to external packages.
The new AddonImpRegistry is well-structured, the ADDON_IMPS mapping correctly replaces the old KnownAddonImps / AddonImpNumbers setup, and the test coverage is strong.
The documentation for foreign addon authors is also clear.

A few concerns worth noting:

• Removal of AddonImpNumbers - this is the only meaningful breaking change.
  Anything downstream that relied on that enum will no longer work. Should be mentioned in release notes.

• Settings dependency - with the static registry gone, ADDON_IMPS becomes the single source of truth.
  When we deploy this, we have to be aware that any misconfiguration here means built-in addons simply won’t register.

• Icon path handling - the parts[-4:] slicing feels brittle and may not work for all external addon layouts.
  Not blocking, but something to revisit.

Otherwise the architecture looks clean, and overall direction makes sense.
Approve with the above noted.

---

Deployment note

When this goes out, we should re-test the main addons (OAuth flow, listing, icons, etc..) to ensure nothing regressed with the registry switch.
Not a blocker - just something to keep in mind during rollout.

CC: @brianjgeiger @adlius @futa-ikeda - highlighting so it’s on everyone’s radar.

[futa-ikeda]

Quick status update: I'd like to release this after we release a smaller feature here #335. This may create an issue where the migration numbers in these PRs will conflict, so once PR #335 is merged, this will need to be updated once more. Hopefully this PR will be merged and released in mid-January, if things go well

[chiku-samugari]

Thanks for the clarification.

I understand that PR #335 will be merged first, and I'm happy to make the necessary updates afterward.
That said, since the current plan mentions completion by the end of this month, I wanted to check whether merging this PR #318 within this month would still be feasible.

[futa-ikeda]

Unfortunately, with the holiday coming up, many people will be out for the next couple of weeks (including myself). I will work to get this out as soon as possible, but it will be January when this is released

[chiku-samugari]

Thanks for letting me know. That makes sense given the timing.
I’m happy to follow up in January once things have settled.