Add an automated DPO/CLA workflow

[dhess]

Ref:

• https://developercertificate.org/
• https://wiki.openstack.org/wiki/OpenStackAndItsCLA
• https://github.com/apps/dco

[dhess]

This should be added org-wide, actually. GitHub supports this, but it might be a bit too limited/restrictive for our needs: https://docs.github.com/en/actions/using-workflows/required-workflows

[dhess]

There may be some issues enabling this feature while using merge queues:

• Add merge_group trigger to enable DCO in merge queue dcoapp/app#200
• dco app doesn't run in merge queues dcoapp/app#199

Possible solutions:

• Use the GitHub API to figure out which PR a merge queue build belongs to: https://github.com/orgs/community/discussions/46757#discussioncomment-5249568
• Detect merge queue builds and automatically report "success": see https://github.com/palantir/policy-bot/pull/554/files, https://github.com/orgs/community/discussions/46757#discussioncomment-5104052. I think this workaround will suffice, because the PR won't even get to the merge queue unless the DCO app is satisfied with the PR in the first place.

Sigh, GitHub Discussions won't auto-expand a rolled-up discussion when you link to a comment that is not shown in the initial fetch, so here is the content of the comment I linked above, for reference:

I currently work around this issue by skipping the action when the event is merge_group and use [github status action](https://github.com/marketplace/actions/github-status-action) to report success status for the required checks.

  mock_report:
    runs-on: ubuntu-latest
    if: ${{ github.event_name == 'merge_group' }}
    steps:
      - uses: actions/checkout@v2
      - name: Skip UI Tests
        uses: Sibz/github-status-action@v1
        with:
          authToken: ${{ secrets.GITHUB_TOKEN }}
          context: 'UI Tests'
          description: 'Skipped for merge queue'
          state: 'success'
          sha: ${{github.event.merge_group.head.sha || github.sha}}

[dhess]

The hosted DCO suffers from occasional failures, causing dependent CIs to stall/fail: dcoapp/app#162

Therefore, I think it makes sense for host to host our own.