Add support for built-in default reviewers

[terlar]

Instead of relying on the Workzone plugin it would be nice if you could also add default reveiwers using the feature that comes out of the box with Bitbucket.

I believe it should be possible to deprecated the old default-reviewers since there is already a separate workzone config for that and the key default-reviewers could be updated to support the built-in one.

I guess it would look something like this:

default-reviewers:
  - source-branch: PRE-**
    target-branch: main
    groups: []
    users: []
    required-approver-count: 1
  - source-branch: feature/**
    target-branch: *

They have a few different modes for the source and target branches but I guess most of them could be achieved with the wildcards.

[robertoaloi]

Hi @terlar , that makes sense. Will see what I can do.

[robertoaloi]

Old comment from a user, which could still be relevant:

Please continue to support Workzone and add support for the native Bitbucket default reviewers feature. The native implementation is limited compared to the Workzone plugin, but has a better UX in the simple cases. If you use the native Bitbucket functionality, the Reviewers field on the Create Pull Request form is pre-populated. I can see upfront that people are being added automatically, and I can remove people from the list (if I want to focus the PR to a subset of the default reviewers). If I use Workzone, the Reviewers list is not pre-populated and I don’t have any indication that it will be. The reviewers are all added automatically after I create the PR. Our team decided we want the default reviewer list to include (almost) everybody, but that we want the flexibility to focus the list down to certain people. Just to clarify, I don't think it's a good idea to have default-reviewers work for both Workzone and native Bitbucket, nor should you drop Workzone and switch exclusively to native. I would appreciate that the bitbucket-erlang-client be simply a programmatic alternative to manually configuring the repo, so that we can maintain consistency among multiple repositories and have the config in version control. It really should not impose additional restrictions on what can be configured.