Remove redundant braille.BrailleHandler.update executions

[burmancomp]

Link to issue number:

fixes #16456

Summary of the issue:

In braille.BrailleHandler._handlePendingUpdate and braille.BrailleHandler._doNewObject functions scrollTocursororSelection function is called. scrollToCursorOrSelection calls scrollTo which in turns calls braille.BrailleHandler.update. Both _handlePendingUpdate and _doNewObject call braille.BrailleHandler.update after calling scrollToCursorOrSelection.

Description of user facing changes

There should be less "Braille window dots" log lines when log level is debug. Maybe some minor effect on performance.

Description of development approach

Minor modifications of _handlePendingUpdate and _doNewObject functions.

Testing strategy:

Local testing in daily use

Known issues with pull request:

none at this moment

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

[LeonarddeR]

This looks reasonable at first sight, though I"m a bit worried about unexpected side effects. This definitely needs a merge early in a release cycle, therefore I'll add the appropriate label for that.

[LeonarddeR]

This pr causes an issue where braille messages aren't properly dismissed when braille changes while viewing them.
For example, on github, try to move to the next heading until the "No next heading" message is shown, then change browse mode cursor. Observe that the "no next heading" message is still shown.