What was the problem? DB drivers can send set of packets in one TCP packet. And usually, they are related to each other and look like Parse + Bind + Describe + Execute + Sync. Driver registers query in Parse, then binds data, then asks to describe types, executes query and commit state. Acra registers PreparedStatement on ParseComplete packet that DB responds to driver after validation and acceptance. Bind packet relates to Parse packet because it should specify statement name for which it sends values.
In this flow acra do next: remembers Parse packet and save it as pendingParse. Then handle Bind packet, loads finds pendignParse and link them together.

Previously we expected that one set of packets in TCP packet contains only one packet with a query like SimpleQuery or Parse packet. And when Acra receives ParsePacket, it resets state, forgets about Bind and other kind of packets - https://github.com/cossacklabs/acra/blob/master/decryptor/postgresql/protocol.go#L121

But drivers not limited in the number of query packets. They can send several of them in one set. And they should be processed in same order. If acra got 2 Describe packets from driver to database and then receives 2 RowDescription responses from the database, it should link first RowDescription to the first Describe, second one to the second.
So Acra should not store only last packet, but should all of them in same order.

In this PR was added new component that stores all pendingPackets and store them separately according to the type, works as a queue. And was refactored logic with working with pending packets. Now it removes item from the queue, not nilify a field.

Due to limitations of python's drivers that don't allow to compile such set of packets to write regression test, were added unit-test with dumped packets that reproduces the problem.

Checklist

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