Add a new INDEX to user_notification_history.notification_history_id to
speed up the notification history retention.
This column is a FOREIGN KEY to notification_history with a "ON DELETE
CASCADE" clause. The notification_history table can be cleaned up by the
notification retention, resulting in lots of DELETE queries. However,
without the INDEX, the DELETE CASCADE might result in a full table scan
for each retention operation.
I have further checked every other retention table, but no other had the
same issue. Most retention tables have their primary key referenced by a
foreign key in the history table, where indexes were already present.
Many thanks to @rezemble for both reporting this issue and coming up
with the exact solution.
Fixes#1003.
