This fixes the issue that the "sweep from browser" would consume the
property before the QR scanner had time to decide it should skip
scanning due to that property existing.
The idea of using Flowee Pay to open a payment screen, or a sweep
screen, was so far married to the executable lifetime due to it being
passed as a command line argument.
This does not reflect reality, on neither desktop nor on mobile as
multi-tasking is possible and we should allow that.
As a result the new object "Intent" has been introduced with the
usecase specific properties. Setting those properties at any time
during the lifetime of the app now pushes the correct page to the
stack on mobile. Desktop is in need of more love in this department.
This allows a user to click on a link in a browser with the bch-wif
scheme and we'll handle that with a sweep page on startup.
To avoid this being just-another-special case we introduce a new
module (read: plugin) concept that is a Start-screen type.
The idea is that we can have a generic handling of this type in
various parts of the app without it being specifically about the
wif handling.
Notice that it doesn't matter if the user has the module enabled,
which just operates the display of the menu option to start it manually.
As we get more modules it turns out that the 'send' tab as originally
envisioned isn't really representative of how we're evolving.
Various items end up being about doing 'stuff' in general. Including
creating a transaction to receive. Only in a very loose way can we
say those are 'send' items.
So, without actually any user-visible changes, this renames the
enum in the module manager and module-section to make it about the
more accurate "action menu".
The Sweep feature needs the 'previous' transactions to build the new
transaction.
This shows a progress-report per-transaction as they are downloaded.
Additionally this splits the incoming electron-X reply into lines before
processing.
This separates it into two objects in order to make thead-safety easy
using Qt's signal/slot mechanism.
Additionally this removes magic timeout numbers and simply starts a
timer to check for changes and emit a signal if the status actually
needs updating.
Testing also shows that QML calls the getter a LOT, so I also moved the
broadcastStatus to be buffered and just return that on the call.
This incidentally also simplifies the code, double win.
tomFlowee