Remove global env variables from organizations

[mattwr18]

Closes #1947

@soey there is still the three_sixty_dialog_partner_token attribute that lives at the organization level, which it probably shouldn't. This is also a value that is global and is not unique to the organization. The token is only good for 24 hours, which makes it difficult to get the value from env variables. Previously, with rails-settings-cached, we would save the value to the db in the settings table and then check to see if there was a value and that it had been updated within 24 hours before asking for a new token, or using the valid one.

Currently, this is used for creating the api key for a newly onboarded client. It then is used to create the templates needed to send out messages for that client.

I think a better way to handle this would be to assume the token is not valid, if it even exists, since we are unlikely to be onboarding multiple clients in the same 24-hour period and always ask for a new token when we run the create api key job. The create template job is currently called from a rake task that collects the templates from our de.yml before scheduling the job. We would need to rethink this flow if we wanted to be able to use the same token to create the templates.

[soey]

Well yes, it doesn't seem "right" to have it on the organization level. It is possible to rework the jobs in a way that they could both be triggered with one fetched token together? If that's hard and much effort to do, I would not oppose against having the storage on the organization maybe just prefix it with "cached_xxx". As I see that we have to touch the whats app integration anyways in some weeks.

[mattwr18]

lgtm

Thanks, as discussed, I've added a bullet point in the list on 360dialog improvements to add back the ability to create single templates on demand. See https://github.com/tactilenews/100eyes/issues/2026