Don't abort connection in mysql after encoding error

[G1gg1L3s]

This PR implements flushing of db-packets till the end of response after the encoding error. This is done to clear the connection so it can be reused for other queries (like rollback for example).

This also adds a couple of tests that show the correctness of the execution. I also wanted to add test with query which produces mysql error after a couple of data packets, so we can check that acra throws "encoding error" earlier and eats the mysql one. But I just couldn't craft such query ._. Mysql returns null in almost every error case (division by zero, unable to allocate REPEAT('A', 1TB), etc). In cases where I could trigger a runtime error it is not possible to use acra, because query is complex. Maybe you can come up with an idea?

Checklist

• [x] Change is covered by automated tests
• [x] The coding guidelines are followed
• [x] Public API has proper documentation in the Acra documentation site or has PR on documentation repository with new changes
• [x] ~CHANGELOG.md is updated (in case of notable or breaking changes)~
• [x] CHANGELOG_DEV.md is updated
• [x] ~Benchmark results are attached (if applicable)~
• [x] ~Example projects and code samples are up-to-date (in case of API changes)~

[G1gg1L3s]

lgtm

and eats the mysql one.

i don't understand for what and what it explain or verify?

I tested the normal workflow. like this:

     +----+ +----+ +----+ +----+
  db |row1| |row2| |row3| | ok |
     +----+ +----+ +----+ +----+

     +----+ +----+ +----+
acra |row1| |row2| |err |
     +----+ +----+ +----+

Where Encoding error happens on the third data packet, so other packets are discarded by acra.

But I also wanted to test this workflow:

     +----+ +----+ +----+ +--------+
  db |row1| |row2| |row3| |mysqlerr|
     +----+ +----+ +----+ +--------+

     +----+ +----+ +-------+
acra |row1| |row2| |acraerr|
     +----+ +----+ +-------+

Where encoding error happens before some mysql one. In that case, the mysql error is also discarded by acra. But this scenario is really hard to simulate ._.

[Lagovas]

Where encoding error happens before some mysql one. In that case, the mysql error is also discarded by acra. But this scenario is really hard to simulate ._.

yes. I think it should be some transaction that fails on commit. and there is should be Parse("BEGIN") + Execute + Parse("insert ...") + Execute + Parse("COMMIT") in same TCP packet. Then database probably will return responses one by one or it will fail on their side and return only error )))