Fix the sized rotating logger size bug for the blf writer

[j-c-cook]

I see two options here:

1. The -s option for the blf rolling logger will not define the file size to be written, but rather the buffer size prior to compression
2. A mathematical equation is to be written that computes the expected file size of the buffer based on the compression integer passed to zlib.compress. (This would require either some knowledge of how the compression functions, or could be an equation fit made from a table of collected values based on a range of compressed buffer sizes vs. the input integer.)

I plan to move forward shortly with a commit that will implement the solution (1).

closes #1359

[codecov]

Codecov Report

Merging #1360 (55401ea) into develop (b9d9d01) will increase coverage by 0.00%.
The diff coverage is 85.71%.

@@           Coverage Diff            @@
##           develop    #1360   +/-   ##
========================================
  Coverage    66.06%   66.06%           
========================================
  Files           86       86           
  Lines         8973     8976    +3     
========================================
+ Hits          5928     5930    +2     
- Misses        3045     3046    +1     

[j-c-cook]

I'm now passing in max_container_size as an option.

[j-c-cook]

Added **options to BLFWriter API.

[hardbyte]

Assuming that compression_level is specific to the BLFWriter, perhaps it should be moved into the options dict as well?

[j-c-cook]

Arguments specific to a Writer could be made more accessible if able to be set by **options . Currently, the only way to set compression_level would be to bypass the Logger (or RollingLogger) object and call the BLFWriter object itself.

When going about these changes, I'll want to make sure that the API is either unaffected by this improvement, or that a deprecation warning is added (similar to what I did here for SizedRotatingLogger).

[zariiii9003]

It is specific to the BlfWriter (and soon Mf4Writer) but i think it's more readable if it is not hidden away in **options

[j-c-cook]

I have confirmed that compression_level can be modified by passing via the argument in **kwargs. @zariiii9003's CLI arguments https://github.com/zariiii9003/python-can/tree/extra_args2 will provide the ability to modify variables such as compression_level. For example:

python -m can.logger -i socketcan -c vcan0 -b 250000 -f file.blf -s 100000 --compression-level=1 --max-container-size=200000

Once #1366 is merged, I will close this PR. The combination of #1367 and #1366 will resolve everything I had intended from this PR.

[j-c-cook]

There is now an adjustable max buffer size.

[j-c-cook]

@zariiii9003 Ready for review.

[hardbyte]

👍🏼

[hardbyte]

Assuming that compression_level is specific to the BLFWriter, perhaps it should be moved into the options dict as well?

[zariiii9003]

@hardbyte i see you approved this but personally i think bringing implementation details of the BlfWriter (options["max_container_size"] = results.file_size # bytes) into the logger script is not a pretty solution.

What do you think about adding a size property to all FileIOMessageWriter subclasses? That way we could delegate size estimation to the logger implementations.