The device watching mechanism does not scale well and might cause performance issues

Description

When subscribing via gNMI, a device sends one response for each path (per change or interval depending on the actually used stream mode). Currently, we spawn a new go routine for each of these responses to handle it. This does not scale well and could crash the controller as it can produce huge amounts of go routines for each device, even worse when trying to observe hundreds of devices at the same time (which is a likely real world use case). An option to deal with this issue is using a fixed amount of workers per device to listen to their own go channel and then forward subscribe responses to their channels (maybe including some kind of queue mechanism) instead of spawning an own go routine per subscribe response. Check gnmi_transport in this merge for more information

Expected Behavior

Actual Behavior

Possible Fix

Steps to Reproduce

Context

Your Environment

  • Version used:
  • Environment name and version (e.g. go v1.16.3 on FreeBSD 13.0-current):
  • Server type and version:
  • Operating System and version:
Edited by Ghost User