🌐 Network Fundamentals

# Example Pull Request Description

## What does this PR do?
Adds error handling and retry logic to Meraki API client

## Why is this change needed?
Current implementation fails when API rate limits are hit.
This adds exponential backoff retry mechanism.

## How was this tested?
- Unit tests added (test_api_retry.py)
- Tested against Meraki sandbox with rate limiting
- All existing tests pass

## Checklist
- [x] Tests included
- [x] Documentation updated
- [x] No security issues
- [x] Follows coding standards

## Related Issues
Fixes #123

PHASE 1: LOGIN AND GET TOKEN
Step 1: User enters username and password into Client App
Step 2: Client sends POST request to /api/v1/auth/login with credentials
Step 3: Auth API queries Database to verify username and password
Step 4: Database confirms user is valid
Step 5: Auth API returns 200 OK with JWT token (e.g., "abc123...")
Step 6: Client App stores the token locally (memory, localStorage, etc.)

PHASE 2: USE TOKEN FOR API CALLS
Step 7: User requests to see device list
Step 8: Client sends GET /api/v1/devices with "Authorization: Bearer abc123" header
Step 9: Device API validates the token is authentic and not expired
Step 10: Device API queries Database for device records
Step 11: Database returns list of devices
Step 12: Device API returns 200 OK with JSON array of devices
Step 13: Client App displays devices to User

KEY INSIGHTS:
✅ Password is only sent ONCE during login (Step 2)
✅ Token is used for ALL subsequent API calls (Step 8, etc.)
✅ Token can expire and requires re-authentication
✅ More secure than sending password with every request

Step 1-2: Script retrieves organization list using API key authentication
  → Response: Organization ID 123 named "Corp"

Step 3-6: Script creates new wireless network in organization 123
  → POST request with network name and type
  → Meraki provisions network in cloud
  → Response: Network ID "net-456" created (HTTP 201)

Step 7-12: Script configures WiFi SSID on the new network
  → PUT request to update SSID 0
  → Cloud controller receives config update
  → Config is pushed to physical Access Point
  → AP applies the configuration
  → Success confirmation flows back through cloud to API
  → Response: 200 OK

WORKFLOW PATTERN:
1. GET (retrieve org ID)
2. POST (create new resource)
3. PUT/PATCH (configure resource)

KEY INSIGHT:
• Cloud-managed: Changes go through API → Cloud → Device
• No direct device access needed
• Centralized management

AUTHENTICATION:
Step 1-4: Script authenticates to DNA Center
  → POST to /auth/token with credentials
  → DNAC validates user in database
  → Returns authentication token (xyz789)

DEVICE DISCOVERY:
Step 5-9: Script initiates device discovery
  → POST device IP address (10.1.1.1)
  → DNAC uses CDP/LLDP to discover device
  → Router responds with device information
  → DNAC stores device in inventory database
  → Returns task ID (202 Accepted - async operation)

TASK MONITORING:
Step 10-11: Script polls for task completion
  → GET /task/{taskId} to check status
  → Returns progress update

TEMPLATE DEPLOYMENT:
Step 12-15: Script deploys configuration template
  → POST with device ID and template ID
  → DNAC pushes config to router via NETCONF
  → Router applies configuration
  → Returns 200 OK (success)

PATTERN:
• Asynchronous operations (discovery returns task ID)
• Polling required for long-running tasks
• Uses NETCONF for device configuration

SUCCESSFUL CONFIGURATION (Steps 1-8):
Step 1-4: Script reads current interface configuration
  → GET interface Gi1 current state
  → Device OS retrieves config
  → Returns interface is disabled (enabled: false)

Step 5-8: Script updates interface configuration
  → PATCH to enable interface and add description
  → Device OS applies the changes
  → Returns 204 No Content (successful, no body needed)

ERROR SCENARIO (Steps 9-13):
Step 9-12: Script attempts to configure non-existent interface
  → PATCH interface Gi99 (which doesn't exist)
  → Device OS checks interface existence
  → Interface not found in configuration
  → Returns 404 Not Found with error message

Step 13: Script handles error gracefully
  → Logs the error for troubleshooting
  → Continues with next operation (doesn't crash)

KEY INSIGHTS:
✅ Always GET before PATCH to verify resource exists
✅ Handle HTTP error codes (404, 400, 500)
✅ Implement try/except in scripts
✅ Log errors for debugging