[X] Add Mastodon ID utilities: these methods are necessary to generate numeric IDs that resemble those that are used in the official Mastodon project. Several of the most popular 3rd-party Mastodon apps, including Ivory, rely on these numeric account IDs. So, these methods lay the foundation for greatly-improved compatibility with 3rd-party apps.
[X] MastodonAccount mostly aligns w/ Masto API spec and Add /api/v1/accounts/lookup + tests: these two commits bring the changes in this PR together. One key change here is the addition of the /api/v1/accounts/lookup endpoint, which was previously missing, and was contributing to various 3rd-party app incompatibilities. With these changes, I was able to refactor the accounts test suite, which was necessary because 3 tests were miscategorized as belonging to /api/v1/accounts/:id when they should have actually been tests for /api/v1/accounts/lookup.
[X] Implement Mastodon account ID: Generate a Mastodon account ID when an AP actor is added to the actors table and add a mastodon_id to any preexisting entry in the actors table as it is retrieved (DB migration not possible in this setting because the value is derived using JS due to SQLite lacking the extensions necessary to build the user-defined function). Again, this is necessary for compatibility with 3rd-party apps and for compliance with Mastodon API specs.
WIP
[ ] Update the code in wildebeest/functions/api/v1/accounts/[id].ts and wildebeest/functions/api/v1/accounts/[id]/*.ts so that they actually use the Mastodon Account ID instead of the ActivityPub actor ID because as things stand now, the implementation is not-compliant with the Mastodon API spec, and it's breaking compatibility with several popular 3rd-party apps
[ ] Update test suite /api/v1/accounts/:id endpoints
Completed
Accountentity/api/v1/accounts/lookupendpoint, which was previously missing, and was contributing to various 3rd-party app incompatibilities. With these changes, I was able to refactor the accounts test suite, which was necessary because 3 tests were miscategorized as belonging to/api/v1/accounts/:idwhen they should have actually been tests for/api/v1/accounts/lookup.actorstable and add amastodon_idto any preexisting entry in theactorstable as it is retrieved (DB migration not possible in this setting because the value is derived using JS due to SQLite lacking the extensions necessary to build the user-defined function). Again, this is necessary for compatibility with 3rd-party apps and for compliance with Mastodon API specs.WIP
wildebeest/functions/api/v1/accounts/[id].tsandwildebeest/functions/api/v1/accounts/[id]/*.tsso that they actually use the Mastodon Account ID instead of the ActivityPub actor ID because as things stand now, the implementation is not-compliant with the Mastodon API spec, and it's breaking compatibility with several popular 3rd-party apps/api/v1/accounts/:idendpointscc @xtuc