Refactor DB to make it more scalable and compatible with Mastodon clients

[CarlSchwan]

Main reasons

• Move from an abstract key-value store for ActivityPub activity to a more optimized relational model that corresponds more closely to what the Mastodon API expects and is more optimized for regular API call
• Separate local and remote account handling: local account can do direct DB calls, remote account needs to do ActivityPub requests
• Use Doctrine ORM to generate DB queries since this simplifies greatly the code base as we don't need to convert db row to object manually and do the joins manually
• Add Mastodon API to add compatibility with thrid party clients
• Follow mastodon general infrastructure to make development more easy (logic is very similar)

TODOs

• [ ] Doctrine
  • [ ] https://github.com/nextcloud/server/pull/33127 (good for many applications in general as it will allow simplifying a lot of things)
    • [ ] Improve annotation caching in production mode
    • [ ] Merge
    • [ ] Alternatively, expose the API in NC25 as private and only move in OCP in NC26
  • [ ] Add migrations to create table (tmp workaround: occ orm:schema-tool:create)
• [x] Create entities
  • [x] Account
  • [x] Application
  • [x] Block
  • [x] Follow
  • [x] FollowRequest
  • [x] Instance
  • [x] Status
  • [x] Mention
  • [x] MediaAttachement
• [ ] Core services
  • [x] TagManager
  • [x] PostDelivery
    • [x] Unit tests
  • [x] TrustedDomainChecker
  • [x] ProcessMentionsService
  • [x] PostServiceStatus
  • [x] AccountFinder
    • [x] Unit tests
  • [x] FeedManager
    • [x] Unit tests
  • [x] InstanceUtils
    • [x] Unit tests
  • [ ] Like
  • [ ] Boost
  • [ ] Follow
  • [ ] ActivityStream
• [ ] Adapt frontend to new API
  • [x] Media upload with the possibility to now add alt text for accessibility
  • [x] Post a status
  • [ ] Timeline
  • [ ] Like
  • [ ] Follow
  • [ ] Boost