This is on the critical path (it blocks getting the compile command for
the first file).
It's not trivially fast: it involves processing all filenames in the CDB
and doing some IO to look for shadowing CDBs.
And we may make this slower soon - making CDB configurable implies evaluating
the config for each listed to see which ones really are owned by the
broadcasted CDB.
nit: we already hold the lock within the loop while reading. it is nice that we no longer need to acquire the lock during destructor, but is it worth the extra mental load that comes with memory orderings? (also IIRC, default load/store behaviors are already acquire-release)