Allow dynamic queue set_concurrency

[apoliakov]

A couple of different requests to set_concurrency and presumaby set_worker_concurrency on queues.

These cases may need to be handled separately:

Case 1:
"To add some context, we want to use DBOS to control the rate of API calls to external providers. The aim is to use a mix of queue concurrency and sleep time to control the rate of API calls, e.g. 10 http requests/second or 2 http requests/second.
Right now we use a single DBOS Step per API call. We have no control over the amount of requests that we send. I see the queue has a limiter limiter that can help us, but I wonder if this can be changed dynamically, instead of having  multiple queues with different settings."

Case 2:
"Example: user A has higher priority so we want to allow higher workflow throughput, like 25 concurrent workflows processing.
User B has less priority so we want to give them 5 concurrent workflows processing.
I get that I could create 2 ‘priority’ queues but I don’t want to be limited to having to explicitly define the configurations."

[jairajc]

I can think of two approached here :

1. Allow Queue Re-declaration : instead of throwing when a queue is declared twice, silently overwrite the in-memory config. Works immediately in single-process deployments since the queue worker reads config on every poll cycle but the issue with this approach that i see is that it will break in multi-worker setups because each process has its own memory e-declaring on one worker never reaches the others.

2. Database-Backed Config (The PR I opened): Add a queue_config table, write limits there on set_concurrency() / set_limiter(), read them back at dequeue time. Solves the multi-worker problem since all workers share the same DB.

The DB approach gets close to solving this but I agree migration overhead other things make this a much bigger architectural commitment.