clarify SubmitShares.Success

it's not clear what the `new_shares_sum` field of `SubmitShares.Success` really means

after reaching out to @jakubtrnka , he described the following:

> `new_submits_accepted_count` is number of submits.
> `new_shares_sum` is "integral" over difficulty of work to be confirmed by this success msg

this commit clarifies both `SubmitShares.Success` and `SubmitShares.Error` with detailed descriptions and new visual diagrams.

Author: plebhash

.idea/vcs.xml

@@ -359,17 +359,21 @@ Because it is a common case that shares submission is successful, this response
 | channel_id                 | U32       | Channel identification                              |
 | last_sequence_number       | U32       | Most recent sequence number with a correct result   |
 | new_submits_accepted_count | U32       | Count of new submits acknowledged within this batch |
-| new_shares_sum             | U64       | Sum of shares acknowledged within this batch        |
+| new_shares_sum             | U64       | Sum of difficulty of shares acknowledged within this batch        |
 
 The server does not have to double check that the sequence numbers sent by a client are actually increasing.
 It can simply use the last one received when sending a response.
 It is the client’s responsibility to keep the sequence numbers correct/useful.
 
+The illustration below assumes a mining server that acknowledges every 10 successful submissions, and that a `SetTarget` message was sent to increase the difficulty from `Da` to `Db` in the middle of the batch submission.
+
+<img width="800" src="img/submit_shares_success.png">
+
 ### 5.3.14 `SubmitShares.Error` (Server -> Client)
 
 An error is immediately submitted for every incorrect submit attempt.
 In case the server is not able to immediately validate the submission, the error is sent as soon as the result is known.
-This delayed validation can occur when a miner gets faster updates about a new prevhash than the server does (see `NewPrevHash` message for details).
+This delayed validation can occur when a miner gets faster updates about a new prevhash than the server does (see `SetNewPrevHash` message for details).
 
 | Field Name      | Data Type | Description                                                 |
 | --------------- | --------- | ----------------------------------------------------------- |
@@ -384,6 +388,10 @@ Possible error codes:
 - `difficulty-too-low`
 - `invalid-job-id`
 
+The illustration below also assumes a mining server that acknowledges every 10 successful submissions.
+
+<img width="800" src="img/submit_shares_error.png">
+
 ### 5.3.15 `NewMiningJob` (Server -> Client)
 
 The server provides an updated mining job to the client through a standard channel. This MUST be the first message after the channel has been successfully opened. This first message will have min_ntime unset (future job).