APIAP: Migrate mapping rules to backend API level

For API as Product, the mapping rules should belong to BackendApi and not to Proxy. That will require a migration to be performed replacing the owner of each ProxyRule while at the same time rebuilding the relationship with proxy in a new table proxy_rules_proxies(proxy_rule_id, proxy_id).

Dev note

Options to migrate `ProxyRule` from `belongs_to :proxy` to `belongs_to :backend_api`

OPTION 1 - maintenance window

1. Stop Saas
2. Change all values in `proxy_rules.proxy_id` to the corresponding `backend_api_id`
3. Rename `proxy_rules.proxy_id` to `proxy_rules.backend_api_id`
4. Deploy code that acknowledges that `ProxyRule` now `belongs_to :backend_api`
5. Restart Saas

Pros: fast, clean, painless
Cons: may cause friction with customers and it’s not our best option in case we need to rollback

OPTION 2 - new `proxy_rules` table

1. Create a new table `new_proxy_rules` (with better name of course)
2. Deploy a temporary version of the code that searches for proxy rules in both tables (old and new) but only saves new records to the new one
3. Copy all records from old table to the new one only changing the value of `proxy_id` to corresponding `backend_api_id`
4. Deploy new version of the code that only knows about the new table
5. Drop the old table

Pros: no maintenance window, safe, best option in case of rollback
Cons: Too long to execute, a lot of code touching only to support intermediary steps

OPTION 3 - new column `backend_api_id` in the old `proxy_rules` table

1. Add a new column `backend_api_id` to `proxy_rules`
2. Deploy a version of the code that acknowledges the new column (but without depending on it – i.e. `ProxyRule` still `belongs_to :proxy`)
3. Run a migration that fills the new column for the old records
4. Deploy a version of the code changing in `ProxyRule` from `belongs_to :proxy` to `belongs_to :backend_api`
5. Drop column `proxy_id` from `proxy_rules`

Pros: no maintenance window, safe, good option in case of rollback, less code touching
Cons: the steps to add and drop columns lock the table

OPTION 4 - polymorphic owner
Similar to OPTION 3, but instead of a new column `backend_api_id`, we add a column `owner_type` and start treating `proxy_id` as polymorphic.
`proxy_id` can be renamed to `owner_id` or not with a tradeoff between locking the table (to perform the renaming) X some hacking in Rails.

OPTION 5 - polymorphic owner without touching `proxy_id`
Add two columns `owner_id` and `owner_type` to `proxy_rules` backfilling them from `proxy_id` and fixed value ‘Proxy’
Deploy a version of the code that acknowledges the new polymorphic owner of `ProxyRule` making sure it’s always filled
Deploy a version of the code that uses only `owner` and no longer `proxy` of `ProxyRule`
Drop column `proxy_id` from `proxy_rules`

together with creating and populating a third table `proxy_rules_proxies(proxy_rule_id, proxy_id)`