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
  • Introduce Doctrine ORM server#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)
• Create entities
  • Account
  • Application
  • Block
  • Follow
  • FollowRequest
  • Instance
  • Status
  • Mention
  • MediaAttachement
• Core services
  • TagManager
  • PostDelivery
    • Unit tests
  • TrustedDomainChecker
  • ProcessMentionsService
  • PostServiceStatus
  • AccountFinder
    • Unit tests
  • FeedManager
    • Unit tests
  • InstanceUtils
    • Unit tests
  • Like
  • Boost
  • Follow
  • ActivityStream
• Adapt frontend to new API
  • Media upload with the possibility to now add alt text for accessibility
  • Post a status
  • Timeline
  • Like
  • Follow
  • Boost