Do not auto-assign bugs for refinement

What does this MR do and why?

Disable auto-assignment of typebug issues for refinement.

Since Threat Insights started using planning issues, the amount of bugs rolling-over to the next milestone has increased.

@nmccorrison and I discussed reasons for this:

1. The issue board is no longer kept prioritized, as we're relying on the planning issue for this.
2. The view in the planning issue doesn't allow us to easily differentiate when a bug is assigned to someone who's working on it, or merely waiting for refinement due to the auto-assignment for refinement by the bot.

This MR addresses the second part by putting EMs in charge of tracking progress on the unassigned bugs. As a side-effect, it's expected that this change will highlight any capacity shortages when it comes to addressing bugs.

It's possible that, as a team, we decide to do away with auto-assignment for refinement altogether. For example, issues belonging to an epic with a DRI shouldn't need to be automatically assigned as the DRI is responsible for seeing that work is progressing, and raising any blockers.

Expected impact & dry-runs

These are strongly recommended to assist reviewers and reduce the time to merge your change.

See https://gitlab.com/gitlab-org/quality/triage-ops/-/tree/master/doc/scheduled#testing-policies-with-a-dry-run on how to perform dry-runs for new policies.

See https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/doc/reactive/best_practices.md#use-the-sandbox-to-test-new-processors on how to make sure a new processor can be tested.

Action items

• If adding environment variables for reactive processors, update config/triage-web.yaml and .gitlab/ci/triage-web.yml
• (If applicable) Add documentation to the handbook pages for Triage Operations =>
• (If applicable) Identify the affected groups and how to communicate to them:
  • /cc @person_or_group =>
  • Relevant Slack channels =>
  • Engineering week-in-review