Add LDAP Support For Subscribers and Multi-User

[nkosi23]

Is your feature request related to a problem? Please describe.
Data on subscribers typically comes from another system (for example a Web Application), and currently we need to export and import the data to listmonk and keep the data up-to-date manually. One may make the situation slightly less painful by using listmonk as the single source of truth for customer data but this is far from being ideal and will not be desirable for anything more serious than a pet project.

Describe the solution you'd like
To avoid duplicating data across applications and the hassle of keeping the same data up-to-date in various places, it would be great to be able to use an LDAP directory as the single source of truth. It will also make defining custom-attributes much easier, since adding attributes is easy in an LDAP directory.

The way I see it, listmonk would need to:

• allow us to set the path to the root of the subscribers tree in the config file
• allow us to set the path to the root of the users tree (for the upcoming multi-user feature) in the config file
• On the import page, allow us to define ldap filters to add subscribers in bulk to a list from the LDAP directory by selecting only the entries matching the filter (it will be the responsibility of end users to add hint attributes to their LDAP directory making these imports easier). End users will be responsible for clicking a button to pull changes from the directory periodically (or this could be done automatically before a campaign is sent, may be an option could let users choose their preferred behavior).
• Either allow us to define the schema for custom attributes on a dedicated page of the UI, or let us reference them in templates without prior configuration while listmonk reads them on the fly when sending campaigns. The last option may be preferable since listmonk will need to read them on the fly anyway since caching all subscribers in postgres is not desirable (especially since LDAP directories are optimized for heavy reads scenarios).

Under this proposal using LDAP would be opt in, for simple setups users would still be able to use listmonk as usual. However the admin will need to make a decision when setting up listmonk (subscriber and user data can either be sourced from postgresql or from LDAP, not both at the same time ).

[knadh]

Closing this in favour of #543.