**Breaking change**: Add resource_name value to file links objects

[leplatrem]

Before, the resource name value was an empty string.

Which makes it mysterious when introspecting the database manually:

SELECT resource_name, COUNT(*) FROM objects GROUP BY 1
;
 resource_name | count
---------------+--------
               |   5217
 account       |     24
 bucket        |     10
 collection    |    380
 group         |    264
 history       |  29061
 record        | 133829
(7 rows)

Let's add a proper resource name.

This change is a touchy breaking change, and would require the following steps:

• set instance as readonly
• run the following query: INSERT INTO objects (id, resource_name, parent_id, data) SELECT id, 'attachments', parent_id, data FROM objects WHERE parent_id = '__attachments__'
• upgrade the app to the new version
• set instance as readwrite again
• delete the old objects DELETE FROM objects WHERE parent_id = '__attachments__'

[alexcottner]

Ah, we don't have a good way for kinto plugins to provide a data migration script.

Can do the required upgrade steps during init, and provide a rollback script in scripts/ in case people need to downgrade? We could make it re-runnable too, right? Something like:

Upgrade would be like...

INSERT INTO objects (id, resource_name, parent_id, data)
SELECT id, 'attachments', parent_id, data
FROM objects 
WHERE parent_id = '__attachments__' and resource_name = ''
ON CONFLICT do nothing;

DELETE FROM objects WHERE parent_id = '__attachments__' and resource_name = '';

Rollback would just invert that.

In the remote-settings case, this should only take moments to run. But there could be a very brief outage where old pods and new pods have some crossover.