feat: isotp discovery - try to discover servers with both padding options by default

[mich41v4294]

Added functionality for the isotp UDS discovery to scan twice by default - once without padding and once with. Abstracted the scanning loop in the process.

[mich41v4294]

I your guys opinions on this: how should be duplicity handled? Is it important to know that the UDS server responds to both padded and non-padded messages? shall we log both or somehow remove the second hit? Unsure how to approach this. @rumpelsepp would you be able to shed more light on this maybe?

As of the 3dd1b32 commit, the code all works good, but logs the targets twice.

[rumpelsepp]

Do you have a specific use case for scanning the padding? In the past we repeatedly failed with reliably discovering the settings for a transport. Consequently, we now consider this as a required prior knowledge for this scanner. There is more prior knowledge that is comparable to this one, e.g., CAN Rate, CAN-FD vs classic CAN, …. Often these settings are known by documentation or by tinkering…

Additionally, the search space will be increased by one byte for the full range; thus increasing the runtime of this scanner significantly.

[mich41v4294]

Do you have a specific use case for scanning the padding?

Yes, some ECUs only respond to one padding configuration and this made me confused when using gallia initially, because the tool I was used to previously did scan with both padding and no-padding automatically, sometimes there's even ECUs with different padding behavior in a single vehicle.

we now consider this as a required prior knowledge for this scanner

I'd argue that it's not the same level of prior knowledge, since the CAN configuration would be defined in the usual documentation (dbc) and it's something you expect to be different on every VUT. Meanwhile you could assume UDS is a common standard and having an unknown here is a bigger problem than in CAN configuration.

CAN settings can also be automatically discovered (on interfaces that support berr-reporting, tested on a PiCAN FD Duo) and along with the padding scanning could serve as an extension of the advanced automation features in Gallia 2.0.

increasing the runtime of this scanner significantly

While this is correct, the PR includes a CLI argument to not perform the scanning twice, but I'm proposing to have automatic as a default, since if you already know if your UDS server needs padding/no-padding, you know that you should look for it as an CLI arg.