Every account gets a fair share of each server

Another account's sandboxes can no longer slow yours down on a shared server. Each server divides its CPU, disk I/O and network bandwidth between accounts first, then between each account's sandboxes: each account keeps the CPU floors it booked, and half of the CPU no floor holds is divided equally between accounts, however many busy sandboxes each runs. One account's sandboxes together use at most half of a server's CPU cores (more only for a single larger sandbox, or for CPU it reserved), and placement books at most half of a server's memory and CPU floors for one account, outside capacity it reserved there. Additional sandboxes are placed on other servers. Booked CPU floors are unchanged. In a test with one account running 16 busy vCPUs on a 4-core machine, a command in another account's sandbox took 28 ms at the median (54 ms at the 95th percentile), against 22 ms (31 ms) with no load and 59 ms (90 ms) before this change. When an account already holds its share of every server in the region that could run a new sandbox, POST /v1/sandboxes returns 429 account_share_full with Retry-After instead of 503 no_capacity, and the SDKs' sandboxes.create waits and retries as it does for no_capacity. This applies to every account, including Runtime's own. See Each account's share of a server.