Limit Productivity Analytics date filtering

What does this MR do?

It introduces start date limit for Productivity Analytics so UI can block users to get further in past than PA was introduced.

Screenshots

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation created/updated or follow-up review issue created
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Performance and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team

Data migration info

Query plan for data migration (tested via #database-lab):

explain SELECT "merge_request_metrics"."merged_at" FROM "merge_request_metrics" WHERE (merged_at > '2019-09-01') AND "merge_request_metrics"."commits_count" IS NOT NULL ORDER BY "merge_request_metrics"."merged_at" ASC LIMIT 1

Limit  (cost=0.43..0.47 rows=1 width=8) (actual time=0.059..0.060 rows=1 loops=1)
   Buffers: shared hit=4
   ->  Index Only Scan using tmp_migration_index on public.merge_request_metrics  (cost=0.43..8293.56 rows=207686 width=8) (actual time=0.057..0.057 rows=1 loops=1)
         Heap Fetches: 0
         Buffers: shared hit=4

Cost: 8293.56

Time: 1.133 ms
  - planning: 1.043 ms
  - execution: 0.090 ms

Shared buffers:
  - hits: 4 (~32.00 KiB) from the buffer pool
  - reads: 0 from the OS file cache, including disk I/O
  - dirtied: 0
  - writes: 0

Closes #32052 (closed)