Reenable Style/HashSyntax EnforcedShorthandSyntax

Description of the proposal

# bad
{foo: foo, bar: bar}

# good
{foo:, bar:}

# good
{foo: bar} # only when the names match can you omit the value

Style/HashSyntax: https://rubydoc.info/gems/rubocop/RuboCop/Cop/Style/HashSyntax

Discussion: Discussion: Enable Style/HashSyntax EnforcedSho... (#477192 - closed)

In !140430 (merged) we disabled the new short hand Hash syntax, since we needed to support Ruby 3.0.

In the latest version of GitLab the minimum is 3.1.x.

I propose we enable this new syntax as is the Rubocop default, since it's more concise and doesn't appear to have any downsides. Though there are 3 options here:

🅰 Enforce the shorthand syntax ({ x: }) (always default)

🅱 Allow both options ({ x: x } and { x: } but not { x: , y: z }) (either_consistent)

👎 Continue to prevent the shorthand syntax ({ x: x }) (never)

Check-list

• Make sure this MR enables a static analysis check rule for new usage but ignores current offenses.
• 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 for both choices, so they are visible to others.
• 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.
• Create a follow-up issue to fix the current offenses as a separate iteration: ISSUE_LINK
• 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.

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