Feature request: Notification center to conform to ActiveSupport notifications API

[jasonkarns]

I have a couple concerns with the instrumentation implementation presently in use.

1. Currently, the Project's notification_center is being type-checked against Optimizely::Notificiation center. This anti-pattern violates one of ruby's core idioms of duck typing. A notification center should only need to conform to the expected API. In particular, as long as the given object responds to send_notifications, then it should be considered a valid notification center.

2. Secondly, the existing NotificationCenter api does not conform to semi-standard notification APIs in Rails land. A de-facto standard API in Rails land is ActiveSupport::Notifications, of which there are many implementations. Conforming to this API would allow existing instrumentation objects within a codebase to be passed to the Optimizely project to handle the new optimizely events.

3. Lastly, the existing NotificationCenter only allows registration of Method listeners. This is completely abnormal ruby, as a normal ruby listener could be a block, proc, or lambda. Even better, it should be anything that responds to call, but at the very least, accepting block/proc/lambdas is table-stakes. (addressed by NotificationCenter should accept any Callable #216 🎉 )

[Tamara-Barum]

My apologies for the significant delay in response to this issue. The team is updating our processes and reviewing all open issues and PR's. If this Feature Request is still relevant, please add your suggestion to our idea portal here https://feedback.optimizely.com/ where it can be evaluated with the other ideas for the product.