Fix pipeline job about about nanosecond

What does this MR do and why?

Fix flaky test job: ./ee/spec/lib/gitlab/usage/metrics/instrumentations/count_ci_environments_approval_required_spec.rb[1:3:1:1:1]

https://gitlab.com/gitlab-org/gitlab/-/jobs/3147919377

Error logs

Failures:
  1) Gitlab::Usage::Metrics::Instrumentations::CountCiEnvironmentsApprovalRequired for 28d time frame behaves like a correct instrumented metric value and query behaves like a correct instrumented metric value has correct value
     Failure/Error: expect(metric.value).to eq(expected_value)
       expected: 2
            got: 0
       (compared using ==)
     Shared Example Group: "a correct instrumented metric value" called from ./spec/support/gitlab/usage/metrics_instrumentation_shared_examples.rb:42
     Shared Example Group: "a correct instrumented metric value and query" called from ./ee/spec/lib/gitlab/usage/metrics/instrumentations/count_ci_environments_approval_required_spec.rb:55
     # ./spec/support/gitlab/usage/metrics_instrumentation_shared_examples.rb:19:in `block (2 levels) in <top (required)>'
     # ./spec/support/gitlab/usage/metrics_instrumentation_shared_examples.rb:9:in `block (3 levels) in <top (required)>'
     # ./spec/support/gitlab/usage/metrics_instrumentation_shared_examples.rb:9:in `block (2 levels) in <top (required)>'
     # ./spec/spec_helper.rb:417:in `block (3 levels) in <top (required)>'
     # ./spec/support/sidekiq_middleware.rb:9:in `with_sidekiq_server_middleware'
     # ./spec/spec_helper.rb:409:in `block (2 levels) in <top (required)>'
     # ./spec/spec_helper.rb:405:in `block (3 levels) in <top (required)>'
     # ./lib/gitlab/application_context.rb:58:in `with_raw_context'
     # ./spec/spec_helper.rb:405:in `block (2 levels) in <top (required)>'
     # ./spec/spec_helper.rb:242:in `block (2 levels) in <top (required)>'
     # ./spec/support/system_exit_detected.rb:7:in `block (2 levels) in <top (required)>'
     # ./spec/support/flaky_tests.rb:27:in `block (2 levels) in <top (required)>'
     # ./spec/support/database/prevent_cross_joins.rb:106:in `block (3 levels) in <top (required)>'
     # ./spec/support/database/prevent_cross_joins.rb:60:in `with_cross_joins_prevented'
     # ./spec/support/database/prevent_cross_joins.rb:106:in `block (2 levels) in <top (required)>'
Finished in 24 minutes 26 seconds (files took 54.56 seconds to load)
2258 examples, 1 failure, 7 pending
Failed examples:
rspec './ee/spec/lib/gitlab/usage/metrics/instrumentations/count_ci_environments_approval_required_spec.rb[1:3:1:1:1]' # Gitlab::Usage::Metrics::Instrumentations::CountCiEnvironmentsApprovalRequired for 28d time frame behaves like a correct instrumented metric value and query behaves like a correct instrumented metric value has correct value

Why it happend

We need to understand this testing process first. it is very simple. Only two steps:

1. Insert two pieces of data into the database and set created_at to 2.days.ago

create_list(:protected_environment_approval_rule, 2, :maintainer_access, created_at: 2.days.ago)

2. Use the condition 30.days.ago..2.days.ago to query the above data.
   the expected result is: 2

The reason for the error is: 2.days.ago in the second step is not working as we thought. It has been rewritten by ActiveSupport and erased the nanosecond part.

Examples

Let me give two more detailed examples to demonstrate how errors can happen by accident

A failed example

1. [2022-10-10 10:20:55.000001] Insert two pieces of data into the database and set created_at to 2.days.ago

created_at = '2022-10-08 10:20:55.000001'

2. [2022-10-10 10:20:55.000002] Use the condition 30.days.ago..2.days.ago to query the above data

where created_at in ('2022-09-10 10:20:55.000000', '2022-10-08 10:20:55.000000') # Get 0 result

A successful example

1. [2022-10-10 10:20:55.999999] Insert two pieces of data into the database and set created_at to 2.days.ago

created_at = '2022-10-08 10:20:55.999999'

2. [2022-10-10 10:20:56.000001] Use the condition 30.days.ago..2.days.ago to query the above data

where created_at in ('2022-09-10 10:20:55.000000', '2022-10-08 10:20:56.000000') # Get 2 result

---

cc @prajnamas @mtan-gitlab