Request Response Subscription manager

[bretambrose]

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 95.96413% with 9 lines in your changes are missing coverage. Please review.

Project coverage is 83.19%. Comparing base (c565837) to head (7074a0d).

Files	Patch %	Lines
source/request-response/subscription_manager.c	96.71%	7 Missing ⚠️
source/request-response/protocol_adapter.c	80.00%	2 Missing ⚠️

Additional details and impacted files

@@                  Coverage Diff                   @@
##           311ProtocolAdapter     #351      +/-   ##
======================================================
+ Coverage               82.86%   83.19%   +0.32%     
======================================================
  Files                      23       24       +1     
  Lines                    9269     9492     +223     
======================================================
+ Hits                     7681     7897     +216     
- Misses                   1588     1595       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sbSteveK]

Just a random thought but would there be any value in adding an 'unsubscribe to all' function that can be called prior to destruction? The unsubscribes would be sent to the mqtt client to be processed (or not processed if the client is also being destroyed) to free up whatever subscriptions the RR had. Would be fire and forget with no wait on acks. This may be useful in a use-case where someone is creating and destroying multiple rr clients over the course of a connection with different names.

[sbSteveK]

Trivial: The aws_rr_subscription_manager_init() would immediately return an AWS_ERROR_INVALID_ARGUMENT error but should we still add a test that insures a max_subscriptions < 1 fails?

[bretambrose]

Just a random thought but would there be any value in adding an 'unsubscribe to all' function that can be called prior to destruction? The unsubscribes would be sent to the mqtt client to be processed (or not processed if the client is also being destroyed) to free up whatever subscriptions the RR had. Would be fire and forget with no wait on acks. This may be useful in a use-case where someone is creating and destroying multiple rr clients over the course of a connection with different names.

That's what aws_rr_subscription_manager_clean_up does