[Hot-Fix] ISS-281939: Two-phase query optimisation for IssueViewSet

[harsh-yadav-shipsy]

Summary

Applies the same two-phase query strategy already shipped on WorkspaceViewIssuesViewSet to IssueViewSet (GET /api/workspaces/{slug}/projects/{id}/issues/).

The problem: The old get_queryset() ran 5 correlated subqueries + 4 select_related JOINs + 3 prefetch_related calls against the entire unfiltered dataset before pagination. On large projects (10k+ issues) this was the primary bottleneck.

The fix — three phases:

• Phase 1 (get_queryset): lean Issue.objects queryset — only scalar filters + one cycle_id annotation. Handles filtering, ordering, and pagination.
• Phase 2 (_build_detail_queryset): count subqueries (sub_issues_count, link_count, attachment_count) run against ~100 paginated IDs only.
• Phase 3 (_enrich_issues_with_relations): 5 flat IN-queries batch-load label_ids, assignee_ids, module_ids, cycle_id, custom_property_values.

Additional fixes in this PR:

• create() was broken after get_queryset() was made lean — it requested sub_issues_count, link_count, attachment_count which were no longer annotated, causing a FieldError. Now uses _build_detail_queryset + _enrich_issues_with_relations.
• Dead import issue_on_results removed.
• Phase-1/Phase-2 null-state mismatch fixed by adding state_id__isnull=False to the Phase 1 filter in both IssueViewSet and WorkspaceViewIssuesViewSet. Django's .exclude(state_id__in=...) silently adds OR state_id IS NULL, letting null-state rows through Phase 1; Phase 2's issue_objects inner-joins on state and would drop them, causing a page count mismatch.
• Debug logger.debug statements added to IssueViewSet for Phase 1 and Phase 2 SQL (mirrors what was done on WorkspaceViewIssuesViewSet before production).

Ticket Information

Link: ISS-281939

How to Test

1. Hit GET /api/workspaces/{slug}/projects/{id}/issues/?layout=list — confirm issues returned with correct label_ids, assignee_ids, module_ids, cycle_id, custom_property_values.
2. Hit with group_by=assignees__id — confirm grouped response; assignees correctly split per group row.
3. Hit with group_by=labels__id&sub_group_by=state_id — confirm sub-grouped response.
4. Hit with group_by=priority (non-M2M) — confirm ordering preserved correctly.
5. Create a new issue via POST /api/workspaces/{slug}/projects/{id}/issues/ — confirm the 201 response includes sub_issues_count, link_count, attachment_count, label_ids, cycle_id.
6. As a guest user (role=5, guest_view_all_features=False) — confirm only created_by=me issues returned.
7. Check Django logs at DEBUG level — Phase 1 and Phase 2 SQL should be visible for IssueViewSet.