Polish subscription listener documentation

References #38

Author: acogoluegnes

src/docs/asciidoc/api.adoc

@@ -884,9 +884,9 @@ no guarantee to be contiguous, the operation may not happen exactly every X mess
 
 ====== Subscription Listener
 
-The library provides a `SubscriptionListener` interface callback to add behavior before a subscription is created.
-This callback can be used to customize the offset the library computed for the subscription.
-The callback is called when the consumer is first created and when the library has to re-subscribe (e.g. after a disconnection or a topology change).
+The client provides a `SubscriptionListener` interface callback to add behavior before a subscription is created.
+This callback can be used to customize the offset the client computed for the subscription.
+The callback is called when the consumer is first created and when the client has to re-subscribe (e.g. after a disconnection or a topology change).
 
 It is possible to use the callback to get the last processed offset from an external store, that is not using the server-side offset tracking feature RabbitMQ Stream provides.
 The following code snippet shows how this can be done (note the interaction with the external store is not detailed):
@@ -903,8 +903,8 @@ include::{test-examples}/ConsumerUsage.java[tag=subscription-listener]
 
 When using an external store for offset tracking, it is no longer necessary to set a name and an offset strategy, as these only apply when server-side offset tracking is in use.
 
-Using a subscription listener can be useful to have more accurate offset tracking on re-subscription, at the cost of making the application code slightly more complex.
-This requires a good understanding on how and when subscription occurs in the library, and so when the subscription listener is called:
+Using a subscription listener can also be useful to have more accurate offset tracking on re-subscription, at the cost of making the application code slightly more complex.
+This requires a good understanding on how and when subscription occurs in the client, and so when the subscription listener is called:
 
 * for a consumer with no name (server-side offset tracking _disabled_)
 ** on the first subscription (when the consumer is created): the offset specification is the one specified with `ConsumerBuilder#offset(OffsetSpecification)`, the default being `OffsetSpecification#next()`
@@ -915,9 +915,9 @@ This requires a good understanding on how and when subscription occurs in the li
 
 The subscription listener comes in handy on re-subscription.
 The application can track the last processed offset in-memory, with an `AtomicLong` for example.
-The application knows exactly when a message is processed and updates its in-memory tracking accordingly, whereas the value computed by the library may not be perfectly appropriate on re-subscription.
+The application knows exactly when a message is processed and updates its in-memory tracking accordingly, whereas the value computed by the client may not be perfectly appropriate on re-subscription.
 
-If we take the example of a named consumer with an offset tracking strategy that is lagging because of bad timing and a long flush interval.
-When the glitch happens and triggers the re-subscription, the server-side stored offset can be quite behind what the application actually processed.
+Let's take the example of a named consumer with an offset tracking strategy that is lagging because of bad timing and a long flush interval.
+When a glitch happens and triggers the re-subscription, the server-side stored offset can be quite behind what the application actually processed.
 Using this server-side stored offset can lead to duplicates, whereas using the in-memory, application-specific offset tracking variable is more accurate.
 A custom `SubscriptionListener` lets the application developer uses what's best for the application if the computed value is not optimal.