KAFKA-5410; Fix taskClass() method name in Connector and flush() signature in SinkTask

Author: ppatierno <ppatierno@live.com>

Reviewers: Ewen Cheslack-Postava <ewen@confluent.io>

Closes #3269 from ppatierno/connect-doc

docs/connect.html

@@ -253,11 +253,11 @@
         private String topic;
     </pre>
 
-    The easiest method to fill in is <code>getTaskClass()</code>, which defines the class that should be instantiated in worker processes to actually read the data:
+    The easiest method to fill in is <code>taskClass()</code>, which defines the class that should be instantiated in worker processes to actually read the data:
 
     <pre class="brush: java;">
     @Override
-    public Class&lt;? extends Task&gt; getTaskClass() {
+    public Class&lt;? extends Task&gt; taskClass() {
         return FileStreamSourceTask.class;
     }
     </pre>
@@ -372,8 +372,9 @@
         }
 
         public abstract void put(Collection&lt;SinkRecord&gt; records);
-        
-        public abstract void flush(Map&lt;TopicPartition, Long&gt; offsets);
+
+        public void flush(Map&lt;TopicPartition, OffsetAndMetadata&gt; currentOffsets) {
+        }
     </pre>
 
     The <code>SinkTask</code> documentation contains full details, but this interface is nearly as simple as the <code>SourceTask</code>. The <code>put()</code> method should contain most of the implementation, accepting sets of <code>SinkRecords</code>, performing any required translation, and storing them in the destination system. This method does not need to ensure the data has been fully written to the destination system before returning. In fact, in many cases internal buffering will be useful so an entire batch of records can be sent at once, reducing the overhead of inserting events into the downstream data store. The <code>SinkRecords</code> contain essentially the same information as <code>SourceRecords</code>: Kafka topic, partition, offset and the event key and value.