backupccl: fix settings registry leak during restore

[pbardea]

Previously, every time a restore data processor was created, a callback
was added to the settings registry to update the size of the pool. This
could potentially lead to a large growth in registered callbacks that
close over the processors created.

This commit replaces that mechanism with a background poller that polls
the cluster setting every 30 seconds to see if the worker pool needs
updating.

Release note (bug fix): Fix a minor resource leak that occurs when a
RESTORE is run.

[cockroach-teamcity]

This change is 

[dt]

I don't love the singleton. If I'm reading correctly, the first settings passed is the one we'll hook up the listener to, but we went out of our way to make settings not a singleton. Tests have a tenant server -- with its settings -- and the real server running at the same time, in the same process, and we've talked about when we might have multiple tenants per process or something.

I think if we really need dynamic resize, I'd just fire up an extra goroutine that on a 5s timer reads the setting and if it changed, resize the existing sem, and pretend settings don't have callback infra at all (indeed, perhaps they shouldn't).

[pbardea]

TRTR!
bors r+

[craig]

Build succeeded:

• GitHub CI (Cockroach)