Added backend changes to sort issues by closed at

What does this MR do and why?

Related to #364757 (closed).

This MR introduces the backend changes needed to sort issues by their Closed at attribute.

Queries

closed_at DESC NULLS LAST

explain SELECT issues.* FROM issues WHERE issues.project_id = 278964 ORDER BY issues.closed_at DESC NULLS LAST LIMIT 100;

Summary:
Time: 12.468 s
  - planning: 7.100 ms
  - execution: 12.461 s
    - I/O read: 35.973 s
    - I/O write: 0.000 ms

Shared buffers:
  - hits: 3508 (~27.40 MiB) from the buffer pool
  - reads: 118591 (~926.50 MiB) from the OS file cache, including disk I/O
  - dirtied: 987 (~7.70 MiB)
  - writes: 0

 Limit  (cost=173140.24..173151.91 rows=100 width=1435) (actual time=12421.735..12461.014 rows=100 loops=1)
   Buffers: shared hit=3508 read=118591 dirtied=987
   I/O Timings: read=35973.123 write=0.000
   ->  Gather Merge  (cost=173140.24..184903.63 rows=100822 width=1435) (actual time=12421.730..12460.981 rows=100 loops=1)
         Workers Planned: 2
         Workers Launched: 2
         Buffers: shared hit=3508 read=118591 dirtied=987
         I/O Timings: read=35973.123 write=0.000
         ->  Sort  (cost=172140.22..172266.24 rows=50411 width=1435) (actual time=12401.844..12401.886 rows=54 loops=3)
               Sort Key: issues.closed_at DESC NULLS LAST
               Sort Method: top-N heapsort  Memory: 229kB
               Buffers: shared hit=3508 read=118591 dirtied=987
               I/O Timings: read=35973.123 write=0.000
               ->  Parallel Index Scan using index_issues_on_project_id_and_iid on public.issues  (cost=0.56..170213.54 rows=50411 width=1435) (actual time=4.766..12296.912 rows=40368 loops=3)
                     Index Cond: (issues.project_id = 278964)
                     Buffers: shared hit=3490 read=118591 dirtied=987
                     I/O Timings: read=35973.123 write=0.000

Details and visualization: https://postgres.ai/console/gitlab/gitlab-production-tunnel-pg12/sessions/10510/commands/37665.

closed_at ASC NULLS LAST

explain SELECT issues.* FROM issues WHERE issues.project_id = 278964 ORDER BY issues.closed_at ASC NULLS LAST LIMIT 100;

Summary:
Time: 15.189 ms
  - planning: 0.532 ms
  - execution: 14.657 ms
    - I/O read: 13.243 ms
    - I/O write: 0.000 ms

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

 Limit  (cost=0.56..141.96 rows=100 width=1435) (actual time=13.361..14.598 rows=100 loops=1)
   Buffers: shared hit=100 read=5
   I/O Timings: read=13.243 write=0.000
   ->  Index Scan using index_issues_on_project_id_and_closed_at on public.issues  (cost=0.56..171067.80 rows=120986 width=1435) (actual time=13.358..14.573 rows=100 loops=1)
         Index Cond: (issues.project_id = 278964)
         Buffers: shared hit=100 read=5
         I/O Timings: read=13.243 write=0.000

Details and visualization: https://postgres.ai/console/gitlab/gitlab-production-tunnel-pg12/sessions/10510/commands/37666.

Screenshots or screen recordings

Timings to apply the migration

main: == 20220616092541 PrepareIndexIssuesOnProjectIdAndClosedAt: migrating =========
main: -- index_exists?(:issues, "project_id, closed_at DESC NULLS LAST, state_id, id", {:name=>"index_issues_on_project_id_closed_at_desc_state_id_and_id", :algorithm=>:concurrently})
main:    -> 0.0248s
main: -- add_index_options(:issues, "project_id, closed_at DESC NULLS LAST, state_id, id", {:name=>"index_issues_on_project_id_closed_at_desc_state_id_and_id", :algorithm=>:concurrently})
main:    -> 0.0004s
main: -- index_exists?(:issues, [:project_id, :closed_at, :state_id, :id], {:name=>"index_issues_on_project_id_closed_at_state_id_and_id", :algorithm=>:concurrently})
main:    -> 0.0232s
main: == 20220616092541 PrepareIndexIssuesOnProjectIdAndClosedAt: migrated (0.0649s) 

Timings to tear the migration down:

main: == 20220616092541 PrepareIndexIssuesOnProjectIdAndClosedAt: reverting =========
main: == 20220616092541 PrepareIndexIssuesOnProjectIdAndClosedAt: reverted (0.0132s) 

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.