Partitioning: Initiate the web_hook_logs partitioning
The first step for partitioning the `web_hook_logs` table (&5558) is to create the initial partitions (covering existing data), add the trigger that will keep the partitioned table in sync with the original table and schedule the background migration jobs that will copy all the existing data. In detail, the following will be covered: 1. Create a new partitioned table with a nearly identical schema as `web_hook_logs`. The only differences will be that the primary key is `bigint` (to address gitlab-org/gitlab#276021) and that the indexes will be missing (to facilitate faster inserts). 1. Create all the monthly partitions that cover the existing data. 1. Install a trigger that keeps tables in sync - in particular it mirrors inserts, updates and deletes into `web_hook_logs` to the newly created table 1. Schedule background migration jobs to copy data from `web_hook_logs` to the partitioned table 1. Add explicit primary key definition to `WebHookLog`. This will not affect the current behavior of the application, but will facilitate the smooth transition when we are going to swap the tables two milestones after the partitioning is initiated.
issue