Add per-query or global throttle to subscription rate

[fnoop]

The subscription update frequency seems to be the same frequency as -api receives messages from its source. If the frequency is too high it overwhelms the various browser mechanisms that take the updates and process and display the data.
Some screens contain several or many queries/subscriptions, each of which update at 10hz or higher. This means the browser may have to process total updates at 50-100+hz which causes performance problems.

We can add two ways to deal with this:

• Client throttle - add a mechanism within -web code to only allow updates per second per message. This has been implemented within the client in a test component, but to add everywhere throughout the code will be quite extensive addition of code.
• Server throttle - add a mechanism within -api to restrict the frequency of subscription updates. This would greatly simplify client implementation.

[SamuelDudley]

I think we could add something into the subscription query and just throttle the data at the -api websocket?

[SamuelDudley]

Throttling at the web socket seems possible, but we need a way to pass the throttle information with the subscription.
@fnoop I'll add a optional maxHz integer variable to one of the subscriptions (say IMU) and we can experiment with that. If you can think of a cleaner way or have other thoughts let me know.

[SamuelDudley]

The client would also need to cancel the subscription and reissue it if it wanted to update the maxHz value.
@fnoop Do you see this as an issue?

[fnoop]

No, sounds good to me :)