Old attachments clean-up configuration option

Is your feature request related to a problem? Please describe.
In our instance we have noticed that the number of shares is quite high, at least when compared with the total number of users and files:

> SELECT count(*) cnt, share_type FROM oc_share GROUP BY share_type ORDER BY cnt;

+--------+------------+
| cnt    | share_type |
+--------+------------+
|      4 |          1 |
|     10 |          4 |
|     24 |          7 |
|     80 |          0 |
|     87 |          2 |
|    206 |          3 |
|   2017 |         10 |
|   7474 |         12 |
|   9458 |         11 |
| 107698 |         13 |
+--------+------------+

These results show that most of the records in oc_share are Deck cards attachments.

Records of this type are created once per every user who has access to a dashboard and per file attached to a card. So if a dashboard is shared among 100 users and a user creates an attachment in a card we will have 100 records in oc_share associated with this dashboard. Of course, if Deck is heavily used (lots of cards, lots of users, lots of attachments), like in the case of this instance, this can grow up quickly.

Describe the solution you'd like
To have a a configuration option to clean-up old shares, similar in logic to what activity_expire_days or trashbin_retention_obligation do.

Describe alternatives you've considered
Manually run a query to DELETE these shares older than a given timestamp. This can be tested before running in production but it is time-consuming and it can lead to metadata loss.

Additional context
In the instance mentioned above, by deleting older attachments we reduced the size of oc_share by 2/3 approximately. End users confirmed that the navigation was way faster after the deletion, probably because of faster join queries with oc_share when generating the views. In any case the question is open: what is the impact of a larger-than-needed oc_share folder?

The issue names no files, tests, or entry points. Start by locating the Deck share and attachment cleanup code and the existing activity_expire_days or trashbin_retention_obligation configuration, then define the retention behavior and verify that cleanup does not remove needed metadata.