Fix: Declare smaller timeouts in F1 DFU to speed up probe upgrades

[ALTracer]

Detailed description

• Not a new feature.
• The existing problem is slow (suboptimal) DFU upgrade times of F103CB-based BMP-compatibles.
• This PR solves this problem by decreasing timeouts returned from BMPBootloader.

This commit from July 2023 resulted from a deeper look into dfu-util operation (and partially bmputil) and BMPBootloader DFU internals (usbdfu, dfucore, dfu_f1). Armed with some DFU operation specs and MCU datasheets for STM32F103CB and GD32F103xx, I added a bit of instrumentation (blinky on dfu_event) to swlink and tried to reduce the timings.

The logic is similar to dfu_f4.c in that there should be two different timeouts for page erase (1 KiB on F1) and buffer program (1024 because of wTransferSize over EP0) calculated from typical or minimum characteristic times (but not maximum). Making the host wait less then come knocking with 1ms polls is safe; and faster than making it wait "for sure long enough". Why that is so -- may need additional argumentation.

Tested on WeAct Studio BluePillPlus boards containing STM32F103CB and GD32F103CB with no regressions (the payload is then manually verified over SWD to match by qCRC) and with a measurable speedup, helpful for both developers often upgrading to daily builds, and for end-users waiting up on the yearly release upgrade.

Example time for a full 120 KiB upload (128 capacity - 8 for bootloader) on current main: 100ms * 120 page erases + 100ms * 120 buffers = 24 seconds, not accounting for synchronous transfer of payload data over USB FS Control EP0.
Example time for a full 120 KiB upload with this patch: 20ms * 120 page erases + 27ms * 120 buffers = 5.64 seconds plus USB exchange. This is, too, a preliminary 4x-5x improvement.
bmputil should benefit from this, too, and it measures upgrade times with a different algorithm than I do with /usr/bin/time -v dfu-util -d 1d50:6017 -s 0x08002000:leave -D src/blackmagic.elf.
Detailed speed tests may be conducted on request. Doing these measurements on a MaskROM USB DFU-capable blackpill-f411ce to replace the bootloader is easier, but F1 parts need either a USB-UART + stm32flash (and BOOT0 button/jumper manipulation) or a proper SWD adapter.
Commit message optionally subject to editing.

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds for hardware native (make PROBE_HOST=native)
• It builds as BMDA (make PROBE_HOST=hosted) -- and is not applicable
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do

Closing issues

[dragonmux]

This LGTM. We'll have Esden double-check this one when he gets a chance on his setup given it impacts the native bootloader, but we've seen you test this change thoroughly over the last several months without issue, so we're of a mind to merge this as-is.

We appreciate too the addition of documentation on where the values come from and why 😄

Thank you for the contribution!

[tlyu]

Confirmed to work on BMP native hardware 2.3b, and speeds things up noticeably. Thanks!