drt: decoupling of the OR singleton from DRT core code

[bnmfw]

Fixes #6532.

DRT Core Dependencies on the ORD singleton

There are two main dependencies DRT has:

1. Getting the Number of Threads.
2. Making reads and writes to the ODB.

The usual abstract interface strategy was used to solve this dependency. A separate ORDBInterface class was created to handle the communication with OR Singleton. The DRT core depends on the Abstract version of this new class and the actual concrete implementation is passed in Run Time during TritonRoute::init().

Number of Threads

Most of the uses of getThreadCount() is now done through the new class. Some cases, in which the number of function calls were not too far from the SWIG code, the thread count is done in the SWIG and passed as a parameter.

For FlexDR.cpp calls, router_cfg_->MAXTHREADS always has the current thread count, so it can be used without harm.

Reads and Writes

This is controversial. The DRT makes 4 separate calls to the ODB, which was pointed to me as possibly being wrong, as the DRT normally should not have this kind of access to the ODB. These are now also done through the new class. There might be a case for all these dependencies to be eliminated in a way that DRT loses access to writing and reading from the ODB.

[github-actions]

clang-tidy made some suggestions

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[maliberty]

@bnmfw I thought we merged a PR for this. Is this stale?

[bnmfw]

@maliberty I think you are referring to #6642. They both tackle the same issue (this closes it), the first solves coupling to the GUI and this solves coupling to the ORD singleton. If follows a similar decoupling pattern as the aforementioned PR, but it solves something different. I also wanted to make this a separate PR due to the debate that could arise from the Reads and Writes part.

[maliberty]

I think the read/write_(lef/def/db) could all be moved to odb. The only tricky case seems to be readDb's callback to sta but that could be handled by an observer. If you make that change in a separate PR it will simplify this one.

Is just inconvenient to plumb the thread count to where it is needed? If so the router config avoid that though I would tend to just pass it through in a more explicit style.