i18n-tasks is only used as a standalone command-line tool. It doesn't
need to be included in the app.
It also prevent a parser warning from appearing when running any rails
command:
> warning: parser/current is loading parser/ruby27, which recognizes
> warning: 2.7.2-compliant syntax, but you are running 2.7.1.
> warning: please see https://github.com/whitequark/parser#compatibility-with-ruby-mri.
Now this (legitimate) warning only appears when running the i18n-tasks
command.
This warning re-appeared when running mailer tests:
```
DISABLE_SPRING=1 bin/rspec spec/mailers/administration_mailer_spec.rb
```
It is now fixed properly, in a way recommanded by the documentation.
For some reason on Rails 6.1 the `after_update_commit` hook is properly
registered – but disappears from the record later, and in the end is
never run.
Fix it by using the general `after_commit` hook instead.
- It was included to make Rubymine happy, but nowadays Rubymine seems
to load the debugger without touching the Gemfile
- It keeps matching an invalid version when `bundle upgrade`-ing the
dependencies.
Turns out we need not only to load the Job constants later, but also
not to do the same work twice – otherwise we'll get a
> ApiEntreprise::Job constant is already defined
when attempting to re-define the constant.
Fix a warning when running tests:
> DEPRECATION WARNING: Initialization autoloaded the constant DynamicSmtpSettingsInterceptor.
>
> Being able to do this is deprecated. Autoloading during initialization is going
to be an error condition in future versions of Rails.
>
> Reloading does not reboot the application, and therefore code executed during
> initialization does not run again. So, if you reload DynamicSmtpSettingsInterceptor, for example,
> the expected changes won't be reflected in that stale Class object.
>
> This autoloaded constant has been unloaded.
>
> Please, check the "Autoloading and Reloading Constants" guide for solutions.
However if we fix as recommanded, the interceptor will get added
each time the classes are reloaded. And as the actual class instance
changed after the reloading, they won't be de-duplicated – *and*
there's no way to remove the old interceptor without having a reference
to the (now-deleted) class.
Instead we load the interceptor once, and add a message about the class
not being auto-reloaded.
