Support for dynamic limits on concurrency

[nhorton]

Right now, key generate accepts a callable, whereas the to setting for the limit is static.

It looks like it would be pretty easy to make that dynamic the same way that the key is.

Would you be open to a PR making that change?

2 notes:

1. A good example motivating use case is SLAs. Premium customers get 2x the number of jobs allowed as standard customers. A second (the one we have) is that we call out to external databases of our customers, and those DBs have different capacity levels, so some could support 1000 jobs at once while some would fall over at 50.
2. I know this could create an issue where the same key could have different limits set by different jobs. I would argue that is a "document and accept it" situation where developers can be warned that it should be the same value for any instances of the same key, and that otherwise the behavior is unpredictable.

[rathboma]

Also interested in this! Surprised there's been no one else weighing in here! Exactly the same situation -- Customer SLAs

[rosa]

Oops, I missed this one completely! This is not really something I plan to implement as I'd like to keep concurrency controls as simple as possible, and for throttling, I'd strongly advise against using this because they add significant overhead. I'd rather have different queues and a different number of workers per queue. You can already set a different queue when enqueuing a job based on the arguments, so that's already supported. I'll document this as an option in the README and will close this one as not planned.

[rosa]

Added in https://github.com/rails/solid_queue/commit/9ae32cb0cbbadd06b22f8f37e2484433af68efd1