Enable RSpec/NamedSubject cop

Description of the proposal

In the MR to enable RSpec/ImplicitSubject (!25025 (closed)), many expressed that they were for the new cop but would prefer if RSpec/NamedSubject was enabled first so we don't create a bunch of new unnamed subjects in our specs.

This MR enables RSpec/NamedSubject while ignoring the many current violations.

https://www.rubydoc.info/gems/rubocop-rspec/1.6.0/RuboCop/Cop/RSpec/NamedSubject

🅰

# bad
RSpec.describe Foo do
  subject { described_class.new }

  it 'is valid' do
    subject.do_something

    expect(subject.valid?).to be(true)
  end
end

🅱

# good
RSpec.describe Foo do
  subject(:user) { described_class.new }

  it 'is valid' do
    expect(user.valid?).to be(true)
  end
end

Check-list

• Make sure this MR enables a static analysis check rule for new usage but ignores current offenses
• Create a follow-up issue to fix the current offenses as a separate iteration: ISSUE_LINK
• Mention this proposal in the relevant Slack channels (e.g. #development, #backend, #frontend)
• If there is a choice to make between two potential styles, set up an emoji vote in the MR:
  • CHOICE_A: 🅰
  • CHOICE_B: 🅱
  • Vote yourself for both choices so that people know these are the choices
• The MR doesn't have significant objections, and is getting a majority of 👍 vs 👎 (remember that we don't need to reach a consensus)
• (If applicable) One style is getting a majority of vote (compared to the other choice)
• (If applicable) Update the MR with the chosen style
• Follow the review process as usual
• Once approved and merged by a maintainer, mention it again:
  • In the relevant Slack channels (e.g. #development, #backend, #frontend)
  • (Optional depending on the impact of the change) In the Engineering Week in Review

/label Engineering Productivity ~"Style decision" development guidelines ~"static analysis"

/cc @gitlab-org/maintainers/rails-backend