Relax type expected for adaptor argument in service's stub

[gbonnefille]

When generating the <<Service>>Stub's methods, the expected type of the adapter is the most specific one. For example, when generating ParameterStub (from MC Area) the asyncGetValue method expect a ParameterAdapter.

While this is semantically exact (if we request a Parameter service, a natural user expect Parameter related returns), such contract avoid usage of more generic adapter. For example, one user can wish to pass an adapter reacting at submitAckReceived level only, just because such adapter is easily reusable with many services.

Is it possible to revise the API to relax the type expected for the adapter arguments, and use MALInteractionListener? Or perhaps can we use the Java capabilities and propose methods expecting the MALInteractionListener and methods expecting the specific <<Service>>Adapter. This second approach will offer the ability to the implementation to have different codes, depending on the nature of the received parameter (current Java implementation immediately upcast the <<Service>>Adapter to MALInteractionListener).

Please, note that such change keep the user's current written code correct.

[gbonnefille]

This issue is related to esa/CCSDS_MO_StubGenerator#20