= Work fetch with max concurrent constraints =

current:
{{{
rr sim: (pick_jobs_to_run) if project reaches a MC limit,
	stop picking its jobs
	(and take it out of the simulation)
	Need to do this to avoid starvation.
work fetch: don't fetch from a project at MC limit
}}}

problem:
we don't buffer work for projects with MC limits

solution:
{{{
rr sim:
	keep simulating project even if at MC limit
	keep track of MI(P,R) = max # instances used by MC projects P
		how many instances the project is able to use, given its MC restriction.
		It may be all instances.
	maintain "MC shortfall" MCS(R,P) for each MC project P
		in update_stats()
			y = MI(P,R) - #devices in use by P
			x = min(y, nidle)
			MCS(R,P) += x*dt
}}}
allow work fetch from MC project P,
	but use MCS(R,P) instead of shortfall; don't request if it's zero

examples (suppose min_buf is 3, max_buf is 6)
{{{
4 device instances
p = project with max concurrent constraint
x = other projects
. = idle
}}}
example 1:
P has lots of work, and can use only 2 instances
{{{
7	pp..
6	pp..
5	pp..
4	pp..
3	pp..
2	pp..
1	pp..
}}}
In this case shortfall is 6,
but we don't want to request any more work from P

example 2:
p has limited work.  It can use 1 or 2 instances, depending
on which app versions run
{{{
7	....
6	**..
5	p*..
4	p*.x
3	p*xx
2	pxxx
1	ppxx
}}}
In this case the MC shortfall for P is 5 (the *'s).
If P had the highest scheduling priority, we'd ask it for 3 units of work.
After that, it wouldn't be eligible for work fetch because
the MC shortfall would be zero.
But we'd be able to ask another project for 4 units.