[tf-module:push-notifications] Allow to define multiple apps per client platform

[lucendio]

NOTE: This is a breaking change and requires Terraform state migration ('terraform state mv')

Due to the fact that multiple different clients (app/build ID) can be connected to
the same backend and at the same time desire to receive push notifications, it should
be possible to register those apps to the same events/notifications queue.

preliminary work for: https://github.com/zinfra/backend-issues/issues/1794

[jschaul]

requires Terraform state migration ('terraform state mv')

Could you document the state migration procedure required in a bit more detail?

[lucendio]

requires Terraform state migration ('terraform state mv')

Could you document the state migration procedure required in a bit more detail?

Sure :+1

[lucendio]

Additionally, @akshaymankar feedback was:

1. Why do we have two platform resources - one for ios and one for android, if they are so little different?

After giving this a little bit of thought, I came to the conclusion, that it would have little value to move them together. The arguments are:

• TF still does not support optional fields in a (nested) object. Without that, it wouldnt make much sense - type-wise - to move ios_applications and android_applications together into applications.
• the code contains some information around the differences between both and points to further documentation. which is helpful if one starts looking into this starting with the code
• (opinion!) overall, I feel it is more readable and I don't mind a little bit of copy&paste in infa code.
• NOTE: I didnt verify whether the AWS API (and Terraform) could deal with platform_principal being set to null in case of Android

2. Dont use a list, use a map and the app ID as key

I had another peek into how our own SNS setup currently looks like. The name of aws_sns_platform_application indeed shows up multiple times, but always with a different platform. So, a map of app IDs as key is not an option in my understanding, especially in cases where platforms may vary in their credentials. Due to this, I will allow the platform to be an array and therefore need to rework the for_each to incorporate the platform in order to make the resource ID.