Rails5: fix mysql milliseconds problem in project_import_state_spec

What does this MR do?

Rails 5 mysql milliseconds fix in project_import_state_spec.rb. Similar to gitlab-ce!20221 and gitlab-ce!20222.

For some specs a be_like_time was not enough because in EE::ProjectImportState#base_delay there is a calculation that does timestamp - self.last_update_started_at. For Rails 4 this value is integer because last_update_started_at still has it's milliseconds as does timestamp, for Rails 5 last_update_started_at is rounded to the second before saving to the db and this value is then not integer. This value is then multiplied by another number leading to a very big difference in calculation for mysql+rails5.

Fixes specs:

rspec ./ee/spec/models/project_import_state_spec.rb:5
rspec ./ee/spec/models/project_import_state_spec.rb:45
rspec ./ee/spec/models/project_import_state_spec.rb:51
rspec ./ee/spec/models/project_import_state_spec.rb:68
rspec ./ee/spec/models/project_import_state_spec.rb:79
rspec ./ee/spec/models/project_import_state_spec.rb:85
rspec ./ee/spec/models/project_import_state_spec.rb:102
rspec ./ee/spec/models/project_import_state_spec.rb:108

See https://gitlab.com/gitlab-org/gitlab-ee/-/jobs/88325552

What are the relevant issue numbers?

Does this MR meet the acceptance criteria?

• Changelog entry added, if necessary
• Documentation created/updated
• Tests added for this feature/bug
• Conforms to the code review guidelines
• Conforms to the merge request performance guidelines
• Conforms to the style guides
• Conforms to the database guides
• EE specific content should be in the top level /ee folder
• For a paid feature, have we considered GitLab.com plans, how it works for groups, and is there a design for promoting it to users who aren't on the correct plan?