Noticed that acra-server inefficiently matches searchable envelopes. It checks only hash header that now should contain first byte zero (0) and have > 32 byte length (sha256). If payload has first byte 0 and 32 bytes more than acra-server decide that probably it is searchable envelope and tries to check it by getting HMAC key and hashing. But it may verify remain payload that it has known signature of any CryptoEnvelope, try to detect other 3 types of headers (acrastruct, acrablock, serialized container). It takes less of computational time than getting HMAC key. Because key is private and encrypted. So we should decrypt it even if it stored in local cache. If it is not in a cache then we should make syscall and read file from file system keystore or even make remote request to Redis (one another keystore backend) just to check that payload is a trash, not a ciphertext.

So, here were added EnvelopeMatcher that uses existing EnvelopeDetector that matches new versioned envelopes and OldContainerDetectorWrapper to match pure AcraStruct/AcraBlock signatures. It uses matchers without any callbacks that make any decryption or other expensive operations, they only try to match signatures in a loop and if finds then up flag about it.

And updated hmac.Processor to use this matcher. If processor matches valid hash signature then it tries to match remain payload to known ciphertext headers. And only after successful check it will do next steps with getting key and verification hashes.

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)