typing: convert db.buildrequests.BrDict to dataclass

[tdesveaux]

Relates to #7591

This one was a bit more annoying.
Contains some fixes/improvements.

Not super happy about the change in _getBuildRequestForBrdict so let me know if you see something better.

Also, since this is planned to be in 3.12, if you create the branch, I can take care of rebase + PR against it.

Contributor Checklist:

• I have updated the unit tests
• I have created a file in the newsfragments directory (and read the README.txt in that directory)
• I have updated the appropriate documentation

[p12tic]

I think the change with _getBuildRequestForBrdict is fine. If it turns out a performance problem we can try optimizing it.

The root cause is having buildername in build request which I think should not live there. But let's not deprecate too much at a single time.

[p12tic]

Looks good, but some tests are broken.

[p12tic]

Also, since this is planned to be in 3.12, if you create the branch, I can take care of rebase + PR against it.

I think for now let's focus on having all pieces in the master branch first. I can easily backport your PRs if you disappear for a month, but if the conversion itself is not finished this would be way worse.

[p12tic]

Also I have some doubts whether backporting to 3.12.0 is the best way to go. The database schema has changed in 4.0, so the backporting will not be trivial and the chance of bugs is increased. The cost of doing this change in e.g. 4.1.0 is just carrying deprecated __getitem__ calls which is a small cost.

One way to go is once 4.0 is otherwise ready, create 4.0.x branch, revert the dataclass PRs that have gone in so far and cut v4.0.0. Master branch keeps going on to be 4.1.0. The cost of doing so is increased number of backports to 4.0.x, but many of the backports will need to go to 3.11.x anyway, so it's not a huge increase of effort.

For you there's nothing to do, if I decide that backporting is bad idea I will adjust the deprecation notices accordingly.

[tdesveaux]

Also I have some doubts whether backporting to 3.12.0 is the best way to go. The database schema has changed in 4.0, so the backporting will not be trivial and the chance of bugs is increased. The cost of doing this change in e.g. 4.1.0 is just carrying deprecated __getitem__ calls which is a small cost.

One way to go is once 4.0 is otherwise ready, create 4.0.x branch, revert the dataclass PRs that have gone in so far and cut v4.0.0. Master branch keeps going on to be 4.1.0. The cost of doing so is increased number of backports to 4.0.x, but many of the backports will need to go to 3.11.x anyway, so it's not a huge increase of effort.

I think pushing this to 4.x is sensible, it could indeed lead to some bugs.
Once all the db have their model merged, I'll look into spawning a test instance of our setup. Although I don't think we cover that much of Buildbot's features, we do have some traffic so that could unearth some things.