It would take ages to go through all files now and assess all belongs_to
associations. So I just declare the old default and then we can move on
and apply the new default for the application while these classes still
use the old one. All new models will then use the new default which is
the goal of this excercise and we can refactor old classes when we touch
them anyway.
This is critical to debug bugs related to subscriptions.
Essentially, `has_and_belongs_to_many` doesn't give us the option for
any other column that the foreign keys themselves:
> A has_and_belongs_to_many association creates a direct many-to-many
> connection with another model, with no intervening model.
Source: https://guides.rubyonrails.org/v3.2/association_basics.html#the-has_and_belongs_to_many-association
Note however, that there's no way to update an order_cycle_schedule,
that I can think of but `updated_at` doesn't do any harm.