Add osgi support for ThingHandlerService implementations.

[cpmeister]

It was mentioned in openhab/openhab-addons#9044 that this would be a useful feature so I went ahead and added support for it here.

Because osgi doesn't support annotation processing for manually created instances, I came up with a workaround that should be acceptable. To take advantage of the osgi @Reference annotations you can make the ThingHandlerService implementation a prototype component and then list the implementation class as the only service.
For example:

@Component(scope = ServiceScope.PROTOTYPE, service = FooService.class)
public class FooService implements ThingHandlerService {
...
}

There are a couple of things goin on here.

1. By scoping the component as a prototype is will force the bundle to create a new instance of the class every time it is requested for, which in our case is every time a new handler is created. Because the osgi system is still responsible for creating instances of the class, it will also handle all of the component annotations (Reference, Activate, Deactivate, etc..) as well. Because a new instance is retrieved each time we can handle the call to setThingHandler after activation. I tried to find a way to be able to call setThingHandler before activation but I did not find any way to do so.
2. By listing itself as its only exposed service, it would prevent any outside bundles from gaining access to the instance after osgi activates a new instance of it. This means that we are still free to perform the interface registrations manually, just as we do currently.

There is a small change that I had to make in the ThingHandlerService interface though.
Since this new method of service initialization can only call ThingHandlerService.setThingHandler after the component has been activated, it would cause confusion and possibly conflicts for users that expect to implement ThingHandlerService.activate() and ThingHandlerService.deactivate(). Since activate and deactivate would happen as part of osgi component creation, users would find that setThingHandler would not yet have been called by the framework. They would only have a null thing handler instance during activate.
To get around this problem I created two new methods initialize() and dispose() which would be called after setThingHandler is called so that users could do proper initialization of their ThingHandlerService.

I hope that all ThingHandlerService implementations will eventually move over to this new naming convention and we can try removing the ThingHandlerService.activate and ThingHandlerService.deactivate methods at some point. I've deprecated those methods in the meantime.

Signed-off-by: Connor Petty mistercpp2000+gitsignoff@gmail.com

[openhab-bot]

This pull request has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/increase-openness-and-competition-on-components-developed-outside-the-official-source-code-repositories/135183/13

[wborn]

Your work got included in #3957 👍