feat: integrate Redis-based session management and improve authentication flow

[Mkalbani]

Summary

• Added @nestjs/platform-socket.io to support WebSocket transport in the Nest runtime stack.
• Introduced Redis-backed session management through a new global SessionModule and SessionService.
• Updated AuthService to create and track sessions during registration, login, token refresh, and logout flows.
• Enhanced logout behavior to invalidate the active session in addition to clearing the refresh token.
• Added distributed locking around session-sensitive operations to reduce race conditions during refresh and logout.
• Refactored cache setup into a dedicated cacheConfig configuration module.
• Added/generated GraphQL schema coverage for assessments and courses.
• Hardened Redis usage across services by attaching connection error handlers to avoid unhandled runtime failures.
• Enabled sticky-session-aware bootstrap behavior and optional cluster mode support for horizontal scaling.

Linked Issue

Closes #201

---

What does this PR do?

This PR introduces Redis-backed session handling to support horizontal scaling and more reliable auth state management across multiple application instances. The authentication flow now creates, refreshes, and invalidates sessions explicitly, while critical session operations are wrapped in distributed locks to avoid concurrency issues. The change also centralizes cache/session configuration, improves Redis error resilience, and prepares the application for clustered deployment and sticky-session load balancing.

---

Type of change

• ✨ New feature (non-breaking change that adds functionality)
• 🐛 Bug fix (non-breaking change that fixes an issue)
• 💥 Breaking change (fix or feature that changes existing API behaviour)
• ♻️ Refactor (no functional change, no new feature)
• 🧪 Tests only (no production code changes)
• 📝 Documentation only
• 🔧 Chore (build, dependencies, CI config)

---

Pre-merge checklist (required)

Do not remove items. Unchecked items without an explanation will block merge.

Branch & metadata

• Branch name follows feature/issue-- or fix/issue-- convention. Current branch is feat/session-horizontal-scaling and should be renamed if the repository enforces the documented convention.
• Branch is up to date with the target branch (develop or main). Pending verification/rebase against the latest target branch.
• All commits and the PR title follow the Conventional Commits format with issue reference. Pending final review of commit history and PR title.

Code quality & tests

• npm run lint:ci — zero ESLint warnings. Pending full-project execution before merge.
• npm run format:check — Prettier reports no changes needed. Pending execution before merge.
• npm run typecheck — zero TypeScript errors. Pending execution before merge.
• npm run test:ci — all tests pass, coverage ≥ 70%. Pending execution before merge.
• New service methods have corresponding .spec.ts unit tests. Session service and related auth flow changes should be covered before merge.
• New API endpoints are covered by at least one e2e test. No new REST endpoints were introduced, but any auth flow or GraphQL behavior considered externally observable should be covered as appropriate.
• No existing tests were deleted (if any were, justification is provided in the PR description)

Error handling & NestJS best practices

• All new/updated DTOs use class-validator and class-transformer decorators and are wired through NestJS pipes (for example global ValidationPipe or explicit). No new DTOs were introduced in this change set.
• All controller entry points validate external input at the boundary (no unvalidated raw any or unknown reaching the domain). Existing DTO-backed auth endpoints remain the entry boundary.
• Controllers/services throw appropriate NestJS HTTP exceptions (for example BadRequestException, UnauthorizedException, ForbiddenException, NotFoundException) instead of generic Error. Auth flows continue to use Nest exceptions for request failures.
• Any new error shapes are handled by existing exception filters or the filters have been updated accordingly. No new HTTP error response shape was introduced.
• Logging goes through the shared logging abstraction (for example Nest Logger or central logger service) with meaningful, structured messages. SessionService uses Nest Logger and Redis clients now guard against unhandled connection errors.
• Authentication/authorization guards (for example AuthGuard, role or permissions guards, custom guards) are applied to all new or modified endpoints where appropriate. Existing protected auth endpoints remain guarded.
• If an endpoint is intentionally public, this is explicitly mentioned in the PR description with rationale. No new intentionally public REST endpoints were added.

API documentation / Swagger

• Swagger / OpenAPI decorators are added or updated for all new or changed controller endpoints (including DTOs, responses, and error schemas). No new REST controller surface was introduced, so no Swagger decorator changes were required.
• I have started the app locally and confirmed the /api (or Swagger UI) reflects new or changed endpoints correctly. Pending local verification before merge.
• If there are no API surface changes, this is explicitly stated in the PR description. No new REST or Swagger API surface was added; the externally visible change is primarily session infrastructure and generated GraphQL schema output.

Breaking changes

• This PR does not introduce a breaking API change
• OR: this PR introduces a breaking change and it is documented below, with migration notes

---

Breaking change description (if applicable)

Not applicable.

---

Test evidence (required)

Commands run locally

Pending final pre-merge verification. Recommended commands:

• npm run lint:ci
• npm run format:check
• npm run typecheck
• npm run test:ci

Manual / API verification

Pending final local verification before merge. Recommended checks:

• Register a user and confirm a Redis-backed session is created.
• Log in and confirm access and refresh tokens include the expected session context.
• Refresh a token and verify the session is reused or rotated correctly under lock protection.
• Log out and confirm the corresponding session is invalidated in Redis.
• Start the app with Redis enabled and verify cluster-mode and sticky-session configuration logs appear as expected.
• Smoke test GraphQL assessment and course operations against the generated schema.
• Open Swagger at /api and confirm no unintended REST contract changes were introduced.

---

Screenshots / recordings (if applicable)

[drips-wave]

@Mkalbani Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits