[BUG] Fix computation of welch's PSD when the number of jobs exceeds the number of channels

[mscheltienne]

Closes #11297
cc @mmagnuski

[agramfort]

just a nitpick. thx @mscheltienne

[sam-s]

please add a test with n_jobs=-1
thank you.

[mscheltienne]

@sam-s n_jobs=-1 will spawn as many workers as there are cores, which on CI is probably 2 anyway (depends on the CI provider).

And to explain the issue and the fix, the input to the // function is split on the channel axis by the number of workers. For instance, if you have 4 channels and 2 workers, both will receive 2 channels. If you have 4 channels and 4 workers, both will receive one channel. And now for the breaking edge-case, if you have more workers than channels, some workers were receiving arrays of shape (0, n_times), i.e. 0 channels, and were put to work on those empty arrays, thus returning nothing and raising during the concatenation of results.
The fix is thus very simple, you don't use more workers than channels even if the user provides an invalid number of jobs for the provided array.

[larsoner]

Marking for merge, thanks in advance @mscheltienne

[sam-s]

@sam-s n_jobs=-1 will spawn as many workers as there are cores, which on CI is probably 2 anyway (depends on the CI provider).

I know, the issue is when -1 is replaced by the actual number of cores - I was afraid that this error might happen before the replacement (and thus you get something like 4 // -1 &c)
I suppose you thought about it already.
Thank you for fixing the issue so fast.

[mscheltienne]

No risk on that side, arguments like n_jobs are checked and converted to a valid value at the beginning of the functions, and I did check locally with -1 anyway ;) Do note however that providing a number of jobs above the number of channels will not yield any performance benefit.