Add --request-delay and --max-concurrency CLI options to reduce API aggressiveness

[marcomobar]

Description

Currently nac-collector makes API calls as fast as possible with no configurable throttling. For controllers like Catalyst Center, endpoints are fetched via ThreadPoolExecutor() without a max_workers limit, and no solution (except Meraki) has proactive delays between requests. This can overwhelm production controllers, trigger rate limiting, or cause instability on resource-constrained devices.

Proposal: two new optional CLI parameters

--request-delay <seconds> (float, default: 0.0)

Introduces a configurable delay between successful API requests. Applied in get_request() and post_request() on the base controller class, so it benefits all solutions uniformly.

nac-collector -s ISE --request-delay 0.5 ...

--max-concurrency <int> (default: unlimited for controllers, 10 for devices)

Caps the number of concurrent threads. Affects:

• Catalyst Center: both endpoint and children ThreadPoolExecutor pools (currently unbounded)
• Device-based solutions (IOSXE/IOSXR/NXOS): replaces the hardcoded max_workers=10

nac-collector -s CATALYSTCENTER --max-concurrency 3 --request-delay 0.2 ...
nac-collector -s IOSXE -d devices.yml --max-concurrency 2 ...

Both parameters default to current behavior, so there are no breaking changes.

I have an implementation ready and would be happy to submit a PR from a fork if you're open to it.