Fixes conflicting association name on project namespace

What does this MR do and why?

Currently there seems to be some sort of a conflict with the project association on project_namespace model. This was initially detected in specs with following code:

p = create(:project)

p.project_namespace.project == nil # this returns true

However loading the project does not result in the same issue:

p = Project.find(project.id)
p.project_namespace.project == nil # this returns false

This can also be reproduced from a rails console through Projects::CreateService

[1] pry(main)> group = Group.first
[2] pry(main)> params = {
[2] pry(main)*   namespace_id: group.id,
[2] pry(main)*   name: 'test1'.titleize,
[2] pry(main)*   path: 'test1',
[2] pry(main)*   description: FFaker::Lorem.sentence,
[2] pry(main)*   visibility_level: Gitlab::VisibilityLevel::PRIVATE,
[2] pry(main)*   skip_disk_validation: true
[2] pry(main)* }
=> {:namespace_id=>22, :name=>"Test1", :path=>"test1", :description=>"Omnis distinctio omnis nemo sequi atque voluptate non.", :visibility_level=>0, :skip_disk_validation=>true}
[3] pry(main)> project = ::Projects::CreateService.new(User.first, params).execute
[4] pry(main)> project.project_namespace.project
=> nil

With the change:

[156] pry(main)> group = Group.first
[157] pry(main)> params = { namespace_id: group.id, name: 'name15', path: 'name15', visibility_level: Gitlab::VisibilityLevel::PRIVATE }
=> {:namespace_id=>22, :name=>"name15", :path=>"name15", :visibility_level=>0}
[158] pry(main)> project = ::Projects::CreateService.new(User.first, params).execute
[159] pry(main)> project.project_namespace.association(:mirror_project).loaded?
=> true
[160] pry(main)> project.project_namespace.association(:project).loaded?
=> false
[161] pry(main)> project.project_namespace.project
=> nil
[162] pry(main)> project.project_namespace.mirror_project
=> #<Project id: gitlab-org/name15>>

#364277 (closed)

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

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.