Serialize service properties
Created by: dblessing
What does this MR do?
Takes service 'properties' and serializes them in a single column. Anything that doesn't need to be queried directly and that may differ between different service types.
This is a straight across change - there are no UI changes or changes to the actual properties for a given service. That will come in other pull requests so this one stays simple and easy to review.
Are there points in the code the reviewer needs to double check?
Please check/test the migration. It seems to work as far as I can tell. However, if something isn't right it could cause a lot of issues for users.
This doesn't appear to break any current tests (well, after some fixing)
Why was this MR needed?
Currently, any service type is limited to a number of attributes: token, api_key, project_url, room, and subdomain.
When adding a new service the developer is faced with a decision to either work within the confines of the current attributes or create a new attribute. Creating a new attribute is overkill because not all services may use this attribute but it will be in the database anyway.
In the future this change could also improve user experience. For example, on some services users are forced to specify user/pass for a service in the project_url. This is ugly and unintuitive: https://user:pass@service.example.com. This also leads to lots of URL manipulation inside the service. After this change we could create properties on a whim: user, pass, and project_url and have a form field for each independently.