Load constants lazily on RailsAdmin initialization

[mshibuya]

This is a counter-proposal for #3492, and aims to fix issues #3490, #3501, #3533, and #3534.

My apologies for those issues. This is because of the complexity in RailsAdmin (and Rails) initialization process, which is hard to get it right. Let me explain the story...

RailsAdmin initializer (config/initializers/rails_admin.rb) is loaded during the Rails app's startup process. But as for the actual configuration (= execution of the DSL itself, the code passed in the RailsAdmin.config do |config| ... end block), there're many constraints that all need to be fulfilled for a successful initialization.

• At this point, basically dependent gems are already loaded but the application codes (e.g. files under app/ directory) are not loaded yet.
• But historically RailsAdmin allows model constants to be passed as the config.model argument. This led to issues like Active Storage: method_missing': undefined method has_one_attached' #3025 in pre-Zeitwerk age, and with Zeitwerk it's not possible because its autoload feature is not enabled at this moment.

So the attempt to address this was made in e4ae669. The idea was basically to delay the execution of the configuration block, after model classes are ready to be autoloaded. But it brought different problems:

• Devise performs reload_routes! on before_eager_load. That means RailsAdmin actions (which are used to construct RailsAdmin routes) need to be set up ahead of that, unless RailsAdmin routes fail to be reflected. To work aronud this issue, reload_routes! was also added in the RailsAdmin initialization process. And that solution isn't perfect, resulting in Reloading Routes before all cause Devise initializers not to be loaded dependent to the order of gem requires #3533.
• Upon the introduction of the Importmap support, RailsAdmin's asset configuration must happen earlier than after_initialize (at that point, it's too late to modify values in app.config.assets). So the configuration execution was brought earlier, but that didn't go well and brought Unable to precompile assets when updating to 3.0.0.beta #3534.

Thus, it's like 2 contradicting forces pulling the initialization timing both forward ant backward. That's why I have been struggling in solving this issue without success...

We need a new way to overcome this problem, and here I have come up with one. That is to intercept const_missing to eliminate the necessity for loading actual classes, while delaying the model initialization by utilizing LazyModel, which is the proven method from pre RailsAdmin 3.x era.
At the first sight overriding Object.const_missing seemed to have side effects, but from what I tested it looks working well. So I want you guys to try this in your setup, and give feedback on whether this is good idea or not.

Thank you for reading this through, and hoping to hearing back!

@codealchemy @jdufresne @q3aiml (or anyone who is interested in this)

[coveralls]

Coverage remained the same at 89.498% when pulling 27002eb on load-constants-lazily into 0ebbd85 on master.

[codealchemy]

I can confirm that this change addresses the issues I was running into in #3534

Some thoughts re: allowing model constants to be used in the initializer.

[mshibuya]

Merged. Thank you for reviewing!

[q3aiml]

This is working well in my testing and resolves #3490. Thank you for figuring this out!