Before this patch the exported users (to csv file that jmeter consumes)
were all the enrolled users in the test course. And that's ok when the
number of users enrolled match the number of concurrent threads planned
for a jmeter plan (each thread is a user).
But when both numbers don't match, that can lead to the jmeter plan
not behaving as expected, because it iterates over the excessive users
in the file, leading to some users having run 5 loops, others 4...
The only way to make results more consistent is to, always, ensure that
the number of users exported for the plan match the plan size and not
the site size.
And that's what this issue exactly does, restrict the export to the
number of threads that the plan will have. So every user always runs
the very same number of loops.
