Add cop to forbid T::Struct uses and autocorrect them to bare classes

[Morriar]

This cop creates offenses for usages of any kind of T::Struct (T::Struct, T::InexactStrict, T::ImmutableStruct) or T::Props (T::Props, T::Props::Constructor, T::Props::WeakConstructor etc.).

For T::Struct, it provides an unsafe autocorrect that translate the struct to a plain old Ruby class so this:

class MyStruct < T::Struct
  const :foo, String
  prop :bar, Integer, default: 0
end

Gets corrected into this:

class MyStruct
  extend T::Sig

  sig { returns(String) }
  attr_reader :foo

  sig { returns(Integer) }
  attr_accessor :bar

  sig { params(foo: String, bar: Integer) }
  def initialize(foo:, bar: 0)
    @foo = foo
    @bar = bar
  end
end

The autocorrect is unsafe as the resulting class does not provide a 1:1 replacement to all the T::Struct behavior and may break existing code expectations.

cc. @rafaelfranca

[KaanOzkan]

👏

[KaanOzkan]

⚠️ This cop is disabled by default and it's not recommended for use by other projects. Disabling T::Struct was something our team thought was best for Shopify's large monolith after investigating the usages and the impact on performance. Here is the internal justification for this decision to give more context:

T::Struct and its associated implementations provide substantial runtime type safety to our code, but this comes at the expense of performance when compared to a standard Ruby class.

Typically, we mitigate any runtime overhead of other Sorbet features by disabling it in production. However, with T::Struct, people have been relying on these runtime behaviors in their code. Disabling the overhead would consequently alter the behavior in production, potentially leading to unexpected results.

Given these circumstances, we believe it's more prudent to deprecate T::Struct usage and rely solely on static checks for type safety. We encourage developers to convert their T::Struct classes into plain old Ruby classes and use signatures on their getter and setter methods to maintain type safety.

By deprecating T::Struct, we want developers to move away from these runtime behaviors and instead use the right tool for the right reason. For instance, Active Record or SmartProperties should be used for data validation, while Active Model is suitable for serialization, among others.

Despite discouraging the continued use of T::Struct, we still strongly encourage you to use signatures to leverage the benefits of type checking.