chore/test: try to filter 300 cookie_range values/pairs on `GET /api/kytos/flow_manager/v2/stored_flows`

[viniarck]

The URL on GET /api/kytos/flow_manager/v2/stored_flows can end up relatively large if a client is filtering for many cookies, we need to double check if unicorn might end up limiting or complaining about the url size and maybe also set it to be larger or move this arg to the body or the request if needed. telemetry_int is trying to optimally filter for the EVCs upfront so we might end up with hundreds of pairs here, so let's test this out.

I'll investigate and test this out tomorrow.

[viniarck]

Also, typically nginx on deployments will be in front of it, so the safest route might be to also accept cookie_range both on query args and request body, and if a client is sending a list that might be big then the client should send it via the request body.

[viniarck]

The good news is that uvicorn doesn't have a hard coded limit for the URI length, so requests going directly over uvicorn instead of hitting nginx wouldn't be an issue. Although it also wastes more bytes to represent the same thing, plus in the request logs it'd be a very large log line, a bit noisy, capturing with wireshark with 500 cookies it resulted in a 16k byte GET header, whereas with json it resulted in 4798 bytes, so clients which will be filtering for hundreds of cookies should prefer to pass the cookie_range filter via json body.

[viniarck]

For future reference regarding nginx default limit values: https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size