Increase reset timeout from 1 to 3 seconds to allow bootloaders to run

[screamerbg]

Increase reset timeout from 1 to 3 seconds to allow bootloaders to run. If you build mbed-bootloader 3.5.0 (the latest at the time of this writing), greentea/htrun will fail the tests because the bootloader takes just above 1 second to run and the application never receives the {{__sync}} message.

To make matters worse, currently greentea/htrun is not picking up forced_reset_timeout from mbed_app.json, only from targets.json. But in 99% of the usecases the bootloader is activated on application config level.

This is pretty urgent as we are not able to test mbed-bootloader with greentea/htrun together.

[coveralls]

Coverage remained the same at 42.424% when pulling 6b7425f on screamerbg:increase_reset_timeout into 1c570ec on ARMmbed:master.

[coveralls]

Coverage remained the same at 42.424% when pulling 6b7425f on screamerbg:increase_reset_timeout into 1c570ec on ARMmbed:master.

[coveralls]

Coverage remained the same at 42.424% when pulling 6b7425f on screamerbg:increase_reset_timeout into 1c570ec on ARMmbed:master.

[screamerbg]

I'm afraid that the proposed PR doesn't fix the problem. When the bootloader takes more time than expected, the sync message never reaches the test application.

Steps to reproduce:

1. Import https://github.com/ARMmbed/smcc-tests
2. Checkout branch htrun-bl-desync
3. Run tests with mbed test -t ARM -m K64F -n simple-mbed-cloud-client-tests-dev_mgmt-connect* -v

If you connect to the board using mbed sterm -b 115200 you can pass it a fake sync message, e.g. {{__sync;0}} and the test will start normally.

[bridadan]

When htrun/greentea were written, bootloaders weren't taken into account with the sync handshake. I think we need to start thinking about how we can accommodate bootloaders.