Whitelist/Blacklist MAC address filtering on first message about ruuvicollector

[Scrin]

Sounds good, you can go ahead and do this change. A few things to keep in mind

• The logic that decides if a mac is allowed or not should be kept separate (like it is now in Config), to support #26
• Try not to make unnecessary changes on the "existing flow", as I have support for "multiple simultaneous inputs and outputs" in progress, which will do some changes to the flow, mainly extracting some of the logic from the Main to separate classes as-is to better support that use-case

[matthewgardner]

If you are actively refactoring main - its probably easier to wait rather than have to handle merge conflicts :)

I also wonder if it would be simplier for the code to read the whole payload (both lines) before handing off to the parsers. Rather than consuming the first part, maintaining state and getting the second message, updating the data object - then processing to an onward store/DB. 🤔

[Scrin]

I'm not touching the main at the moment (apart from testing changes), I'm developing a http-gateway input feature in completely separate classes. Once that's done I know which parts of the current hcidump input feature it actually overlaps with and I will then split the relevant parts accordingly to their own respective classes. At the current amount of free time I have for this project this will be relatively far in the future.

Regarding the parser, it needs to be more or less a state machine anyway, as some of the structural information (such as report and AD counts and lengths) are not known until you've already parsed up to the point where they are declared, so I figured it could as well parse the input in pieces to avoid the need of manually stitching the lines together beforehand. It wouldn't be thread-safe anyway, so parsing in pieces makes no difference in that. I was actually initially considering creating the parser with java.io.Reader/java.io.Writer, but then decided not to, as it wouldn't really bring any benefit in the current use-case.

Another issue in stitching the lines is that you don't know how many lines there will be without starting to parse the packet and figure the lengths, so you'd need to wait for the next new packet (a line starting with > or <) which will cause an unnecessary delay (and thus skew the measurement timestamp), especially in setups where packets come in at much longer intervals.

[matthewgardner]

Had an attempt at this - let me know if I have missed anything :)