Turn off repo setting that all PRs must be on the latest main

[tjprescott]

Based on a true story...

• Spend 20 minutes waiting for CI to turn green so you can merge PR.
• At minute 19 someone merged a docs PR and not you can't merge yours because you are not on the latest in main.
• Rebase or merge and wait another 20 minutes. Hope no one else merges something in the meantime...

This repo setting isn't set for any of the other repos I work in like azure-rest-api-specs and azure-sdk-for-python and it works fine. It only forces you to merge or rebase if there are conflicts. Is there something about submodules that necessitates this policy?

[timotheeguerin]

We just had many instances of 2 prs conflicting and making the CI fail in main branch requiring a fix to be made or it blocked everybody.

[nguerrera]

I recall my main motivation for turning this on reluctantly was when we shipped with changes in a release without their changelogs. There's a race between the publish PR and the actual publishing in CI. If someone checks in a change while the publish PR is pending then when the publish PR merges, it will publish their change too, but their changelog will be in the next release not the current one.

I put in a check that there are no more changelogs to prevent this, but it requires that you cannot merge the publish PR without running validation against it with all the changes that are already in.

That said, I'd be happy if we find a better publish process to solve this. For example, fully automating the process and having it snapshot a branch from which the release is done to keep main unblocked while in progress.

[tjprescott]

Do we tag the release? Then we could target the specific tag for creating the changelog.