feat: send or unsend matcha messages

[mavonx]

What?

Messages are held for N seconds before delivery, with a recall window.

Why?

Saves users from sending mistakes, just like Gmail/Outlook.

Closes #1139

[floatpanebot]

Benchmark report — no significant change

Metrics worse: 0 · better: 0 (threshold: ±3%).

benchstat output

goos: linux
goarch: amd64
pkg: github.com/floatpane/matcha/backend
cpu: AMD EPYC 9V74 80-Core Processor                
                           │    old.txt     │               new.txt                │
                           │     sec/op     │    sec/op      vs base               │
ParseSearchQuery_Simple-4     2.889µ ± 219%   2.587µ ± 403%        ~ (p=0.394 n=6)
ParseSearchQuery_Complex-4    6.817µ ±  45%   5.907µ ±  40%        ~ (p=0.589 n=6)
TokenizeSearchQuery-4        14.285µ ±  63%   4.265µ ± 238%  -70.15% (p=0.015 n=6)
geomean                       6.552µ          4.024µ         -38.58%

                           │  old.txt   │              new.txt               │
                           │    B/op    │    B/op     vs base                │
ParseSearchQuery_Simple-4    26.00 ± 0%   26.00 ± 0%       ~ (p=1.000 n=6) ¹
ParseSearchQuery_Complex-4   762.0 ± 0%   762.0 ± 0%       ~ (p=1.000 n=6) ¹
TokenizeSearchQuery-4        176.0 ± 0%   176.0 ± 0%       ~ (p=1.000 n=6) ¹
geomean                      151.6        151.6       +0.00%
¹ all samples are equal

                           │  old.txt   │              new.txt               │
                           │ allocs/op  │ allocs/op   vs base                │
ParseSearchQuery_Simple-4    2.000 ± 0%   2.000 ± 0%       ~ (p=1.000 n=6) ¹
ParseSearchQuery_Complex-4   23.00 ± 0%   23.00 ± 0%       ~ (p=1.000 n=6) ¹
TokenizeSearchQuery-4        9.000 ± 0%   9.000 ± 0%       ~ (p=1.000 n=6) ¹
geomean                      7.453        7.453       +0.00%
¹ all samples are equal

pkg: github.com/floatpane/matcha/tui
                    │   old.txt    │              new.txt               │
                    │    sec/op    │    sec/op     vs base              │
LogPanelView-4        178.4µ ± 61%   161.2µ ±  9%       ~ (p=0.065 n=6)
SearchOverlayView-4   172.0µ ± 19%   179.8µ ± 10%       ~ (p=0.589 n=6)
InboxConstruction-4   937.6µ ± 12%   938.6µ ± 13%       ~ (p=1.000 n=6)
geomean               306.4µ         300.8µ        -1.83%

                    │    old.txt    │               new.txt               │
                    │     B/op      │     B/op       vs base              │
LogPanelView-4        44.67Ki ± 51%   44.67Ki ± 51%       ~ (p=1.000 n=6)
SearchOverlayView-4   56.14Ki ± 41%   56.15Ki ± 41%       ~ (p=0.275 n=6)
InboxConstruction-4   874.3Ki ±  0%   874.2Ki ±  0%       ~ (p=0.279 n=6)
geomean               129.9Ki         129.9Ki        +0.00%

                    │   old.txt   │              new.txt              │
                    │  allocs/op  │  allocs/op   vs base              │
LogPanelView-4         714.0 ± 0%    714.0 ± 0%       ~ (p=1.000 n=6)
SearchOverlayView-4    926.0 ± 0%    926.0 ± 0%       ~ (p=1.000 n=6)
InboxConstruction-4   3.478k ± 0%   3.478k ± 0%       ~ (p=1.000 n=6)
geomean               1.320k        1.320k       +0.00%

_{auto-generated by benchmarks.yml}

[andrinoff]

/backport v1

[andrinoff]

1. Inline images are broken, when sent to QueueEmail (not passed)

2. I'm pretty sure, that the daemon has no countdown, it just fires delete, even though UI says that it's going to do it in 10 seconds

3. Keybind should be in keybinds.go (reconfigurable)

4. Maybe, configure delays in the config

5. A nitpick, but, if the daemon crashes in the state of "Sending in n seconds" queued emails will not be sent

[andrinoff]

@mavonx 1 and 2 are critical, 3 is important, 4,5 optional

[andrinoff]

I'll review later changes in the evening

[mavonx]

1. Inline images are broken, when sent to QueueEmail (not passed)
2. I'm pretty sure, that the daemon has no countdown, it just fires delete, even though UI says that it's going to do it in 10 seconds
3. Keybind should be in keybinds.go (reconfigurable)
4. Maybe, configure delays in the config
5. A nitpick, but, if the daemon crashes in the state of "Sending in n seconds" queued emails will not be sent

@andrinoff

Regarding the second point, I see two possible approaches:

1. Remove the countdown from the TUI and keep it only in the daemon. In this case, we won't have a countdown displayed in the TUI; I'll simply show "Sending... (u to undo)". I recommend this approach, as it's similar to how Gmail handles it in their demo.
2. Remove the countdown logic from the TUI and have the TUI request the countdown value from the daemon in order to display it.

[andrinoff]

Whichever you want, maybe a timer looks like a ticking bomb and Gmail/iCloud mail style would be better. also, I'd like to add to the configurable countdown, that it should be around 5 seconds default, not 10