Fix test-linux-stable excessive run time

[mateo-moon]

Add nextest config file. Aside of default config add mutual exclusion group(bottom of the file). This group is limited to one thread, meaning that tests from the group will be executed sequentially. This is because tests falling in this group run cargo build and multiple invocation of cargo build lead to clottering execution.
By using test group we could achieve 1 minute faster result than just using 1 thread for all tests)

[mateo-moon]

Closes paritytech/ci_cd#754

[ggwpez]

This is because tests falling in this group run cargo build and multiple invocation of cargo build lead to clottering execution.

So is it as fast as before the bug occurred? Can you give a short before/after timing please?

[bkchr]

cargo build and multiple invocation of cargo build lead to clottering execution.

You mean too many parallel execution brought down the CPU?

[mateo-moon]

This is because tests falling in this group run cargo build and multiple invocation of cargo build lead to clottering execution.

So is it as fast as before the bug occurred? Can you give a short before/after timing please?

I don't have before results. I don't know when "bug" occurred. Mb you could share the link of the invocation in the past so i could compare.
Although i doesn't seem like a bug in nextest to me. I don't actually understand how did it work properly before. But if it's really the case, than i think something has been changed in cargo. Mb with new version update something was changed.
About current set up performance. With one dedicated thread for this group it toll 13 minutes for a whole test run.
I've added new parameter with thread-requiered and set it to 16. It should improve things. Nevermind. This setting is for group of tests not for a separate test. Doesn't help in our case.

[mateo-moon]

cargo build and multiple invocation of cargo build lead to clottering execution.

You mean too many parallel execution brought down the CPU?

No, it's not that. Every test by default nextest config is dedicated to one Core. It's more likely because of some kind of the race condition in cargo build. I found this hint in this thread.
I was able to get ui tests properly ran only when they executed sequentially.
Have no idea how it worked before.

[bkchr]

cargo build and multiple invocation of cargo build lead to clottering execution.

You mean too many parallel execution brought down the CPU?

No, it's not that. Every test by default nextest config is dedicated to one Core. It's more likely because of some kind of the race condition in cargo build. I found this hint in this thread. I was able to get ui tests properly ran only when they executed sequentially. Have no idea how it worked before.

Interesting! Maybe some issue in Cargo itself.