Zip entry offsets

[IvanBorislavovDimitrov]

The core logic of reading the zip streaming is changed:

1. Start reading the archive stream (entry by entry)
2. Get the data offset of the entry (apache compress supports it out of the box)
3. Read the stream until -1 is returned, this means the entry is read
4. Zip input stream from apache compress stores the "compressed" entry size so the end index of the entry is data offset + compressed size (there is a method) -> it is only calculated correctly when the zip stream has returned -1 (the zip entry is read). It gets the compressed size from the internal inflater.
5. Store information about the compression method of the entry
6. If the entry's compression method is 8 this means it must be inflated (it is DEFLATED), so for this type of entries create a new Inflater(true) ->true means no wrap (it will inflate from the exact indexes of the entry). If the entry's compression method is 0 this means it is STORED, in this case just read the bytes and store them (you have the entry)
7. Now you have stored the data offset and the end offset for each entry. When you need a specific entry, just pass the start and end index to clouds, and it will return the stream only for this entry, which again should STORED / INFLATED depending on the compression method

[sonarqubecloud]

Quality Gate failed

Failed conditions
68.6% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

[IvanBorislavovDimitrov]

Coverage is lower because of the backwards compatibility logic and SQL providers that only throws exceptions