The milestone filter in the `Repository.issues` GraphQL connection is
broken, so switch to the Search API for any milestone filtering.
Previously, we used to work around this by obtaining the milestone
database ID from decoding the GraphQL ID, but that no longer works since
the GraphQL ID format has changed.
For metadata types chosen in interactive flow, we fetch all records from
the API in order to be able to display a multi-select interface.
For metadata defined via command-line flags, we resolve records that can
be looked up directly, avoiding fetching the entirety of expensive
datasets (e.g. all members of an organization) if we can.
The new approach ensures efficient fetching when interactive flow is
combined with values from flags.
We no longer guess the head repository using heuristics; instead, we
present the user with the choice of pushable repositories and an
additional option to create a new fork.
The new `pr create --head` flag is available for the user to specify the
head branch in `branch` or `owner:branch` format and completely skip any
forking or auto-pushing checks.
Any errors from fetching and rendering the README were silenced and
ignored in `repo view`. This change:
- Tolerates HTTP 404, but will raise exceptions for any other error;
- Moves markdown rendering from `api` package to command implementation;
- Ensures markdown rendering errors are correctly reported.
First, consolidate the functionality between `pr merge` and `pr
checkout` that resolves the default branch name of the base repo. With
an added bonus, the new approach avoids an API request when one isn't
necessary.
Then, ensure that checking out 3rd-party PRs will result in local branch
name such as `<owner>/<branch>` when the head branch of the repository
matches the default branch of the base repository. We already have had
code in place to take care of this, but it only took effect in the `pr
checkout <number>`-style invocation.
