Make code_reload act regardless of diagnostics

[fabjan]

Description

See #1409 for background. Given that hot-reloading from an editor is a development feature it should not matter if there are diagnostic errors while iterating.

The reason I moved the code out from els_compiler_diagnostics is that it seemed a bit misplaced in there and looking at commit history it looks like code reload was added before the els_diagnostics behavior existed, and it was just inside els_text_synchronization_provider. If it is to be detached from diagnostics results it seems there is little reason to keep it in els_compiler_diagnostics.

Fixes #1409

Extras

Stop trying to compile and reload files that are not ".erl" files. It doesn't work and just gives popup spam.

Testing

The moved test cases work fine. I also manually tested that code reloading still works.

Notes

If the remote node has a cookie it is not possible to configure code reload to work with it. Perhaps the "code_reload" section in the config file needs to get a "cookie" attribute (but for a future PR I guess).

[dweinstein]

I tend to agree with @fabjan here. It's weird to get spurious errors like "code_reload swap crashed for: erlang_ls.config with: error" when opening/saving the erlang_ls.config file or *.app.src files.

I'd say either this change or an option in erlang_ls.config so that if I hit save on a file it tries to reload regardless of anything else such as warnings. I've found that it's quite confusing that, e.g., I have this issue #1044 and due to that it wouldn't code_reload my cowboy handler.

[dweinstein]

separately @fabjan

If the remote node has a cookie it is not possible to configure code reload to work with it. Perhaps the "code_reload" section in the config file needs to get a "cookie" attribute (but for a future PR I guess).

putting the cookie into the erlang_ls.config doesn't sound like a good idea since that would be committed? Seems like something to pick up from another file or environment variable instead?

[fabjan]

putting the cookie into the erlang_ls.config doesn't sound like a good idea since that would be committed? Seems like something to pick up from another file or environment variable instead?

That sounds like a better idea. However, there is already a cookie setting in the config, so I figured this might have been considered already:

erlang_ls/apps/els_core/src/els_config_runtime.erl

Line 71 in 229175e

-spec get_cookie() -> atom().

Maybe the scope for the runtime config is very specific and "LS-only", so to speak?

[plux]

Thanks for your contribution @fabjan !