Add manually-triggered debugging workflow

[mhucka]

This workflow is designed to let you run pytest with various debugging options. It's meant to be executed manually using the "Run workflow" button on https://github.com/quantumlib/Cirq/actions/workflows/debug.yaml

Clicking the "Run workflow" button there will make GitHub present a form interface with various options for the characteristics of the run. (See screenshot at right.) Options include:

• give it a specific test to run (in the form of a path to a test file)
• set the number of repetitions of the test
• set the python version to use
• set the random seed
• turn on verbose logging

This workflow was developed as an aid to debugging issue #6906, involving curve fitting that failed on occasion. This workflow is general and I think it will be useful for other debugging needs.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.87%. Comparing base (0361a81) to head (dbb5871).
Report is 5 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6918   +/-   ##
=======================================
  Coverage   97.87%   97.87%           
=======================================
  Files        1084     1084           
  Lines       94420    94447   +27     
=======================================
+ Hits        92409    92436   +27     
  Misses       2011     2011           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pavoljuhas]

Thank you for adding this @mhucka. A couple of questions for future reference -

1. Can this be triggered for a pull request from forked repository?
   The "Use worfklow from" menu shows only branches and tags in the main repo.

2. I assume non-member GitHub users cannot run this, is that correct?

[mhucka]

1. Can this be triggered for a pull request from forked repository? The "Use worfklow from" menu shows only branches and tags in the main repo.

A person should be able to run it in their fork on GitHub. The user may first need to enable running workflows from forked repositories in their fork's repository settings, and if their repo is under an organization, that setting may be controlled at the org level, which means it might require permissions adjustments by the org admins. Also, the workflow will run in their forked environment (using their tokens etc.).

However, as currently set up, I don't think a user could run it from the Cirq repository interface on their fork. So, the interface at https://github.com/quantumlib/Cirq/actions/workflows/pytest-debug.yaml won't let it be run on a pull request from a fork. However, the user themselves should be able to run it from https://github.com/USERACCOUNT/Cirq/actions/workflows/pytest-debug.yaml.

I guess the upshot is that users can run it for themselves on their own repo, but we can't run it on their pull request.

2. I assume non-member GitHub users cannot run this, is that correct?

As I understand it, to manually trigger a workflow using workflow_dispatch, a user must have write access to the repository, so basically that's correct; however, I think it's possible to give special permissions to individual users, so it might be possible to grant the privileges to non-member users.

I'm not sure what non-member users will see in the GUI interface – I don't know whether that means the "Run workflow" button doesn't show up at all for them, or something else happens.