Add a lint workflow to fail on eslint warnings

[Minion3665]

As discussed on Matrix the set of things we want to pick up in CI and development are different. Specifically, there are some things that only get in the way during development but should not be allowed in merged code. Examples are 'debugger' statemens, dead code (e.g. resulting from 'if (false)') and unused variables.

After #7822 there are no more eslint warnings, so we can use it as a separate state for these issues that should only block in CI.

This commit adds a new workflow which will run eslint and fail if it receives any warnings, and changes those 3 errors so that they only emit warnings.

It's expected that there are more annoying warnings which I've missed, if you have any please make a followup change!

This commit explicitly does not deal with formatting-related issues (e.g. requiring single quotes for strings in eslint) as though they can be annoying there's no reason why they should change between development and master... another followup to improve linting experience could be to use an autoformatter so the computer fixes the formatting for you, however that's out-of-scope for this commit

Change-Id: I036afac5ef5056a9cc2effc21e31165aa1436ad2

• Resolves: #
• Target version: master

Summary

TODO

• ...

Checklist

• Code is properly formatted
• All commits have Change-Id
• I have run tests with make check
• I have issued make run and manually verified that everything looks okay
• Documentation (manuals or wiki) has been updated or is not required

[vmiklos]

Looks reasonable to me (we have a similar setup for core: clang plugin warnings are enforced at CI time but you are not required to respect them during local development). But I prefer if @eszkadev have the final word on this, I don't do enough work on the JS side to decide.

[eszkadev]

I'm wondering if we could maybe put more strict eslint check into make check which is run on CI.
This has advantage that doesn't waste CI time. While in proposed approach GH action will fail but cypress still will be continued.
I think you want to have possibility to run that strict check locally too... so would be good to put into Makefile.

So:
make run - goes with regular eslint - no errors, warnings are ok
make check - does strict eslint check - no warnings or errors

[Minion3665]

I'm wondering if we could maybe put more strict eslint check into make check which is run on CI. This has advantage that doesn't waste CI time

This makes sense, I wonder if we should run it in both CI and a GitHub action ... that way if we're waiting in a queue for CI we'll still get input eslint failures quickly

[eszkadev]

We can always do eslint before c++ unit-tests in make check and it will be quick enough?