gcc-10.2 in the current git correctly deduces the expression :(
only tested this with the new gcc, fix the current release build

resolve #2327, #2220

- remove legacy support in the webui
- format datetime strings on the device, use NTP panel to display them both
- migrate from the old ntpOffset + ntpDST + ntpRegion to ntpTZ

resolve #2310

also, drop special builds flags in favour of sane defaults

ensure the only operation from main loop() is load
since isr handles incrementing the counter, resulting value is calculated as
offset between the current and the previous reading (always positive)

- inject dummy data sequence that is expected to hold current version info
- check rtcmem markers and purge settings, since we don't want accidentally reading something as a kv
- sometimes we cannot boot b/c of certain SDK params, purge last 16KiB as well

ref. `SetOption78 1`
https://tasmota.github.io/docs/Commands/#setoptions

The original idea from Esphome:
0e59243b83/esphome/core/esphal.cpp (L275-L287)
Does not seem to be working atm. Will need to re-check with the esphome builder, c/p did not work and I tried building with gcc-10

Specific things we want to do is to have 'version' byte between 2 'marker' bytes:
217addc2bb/tasmota/settings.ino (L218-L262)       0dfa38df89/tasmota/i18n.h (L780-L782)

Optimize isr handler once more by removing gpio -> index conversion at runtime

Drop atomics for now, since we can also make the whole operation atomic
by locking GPIO interrupts while reading and setting the counter value
And we don't have another thread / core to worry about

amend 8252f2ae18
note that platform does not implement either fetch_add or exchange

clean-up ordering once again

resolve #2368

- Fixes "undefined reference to `__atomic_fetch_add_4'"
  Notably, std::atomic_fetch_add(&counter, 1) would also trigger this.
  std::atomic<T>::operator+= does not allow in-place change, since it
  returns T instead of T&
- Another work reduction in the isr, treat 'value' as `counter > 0`
  instead of relying on the notion that we can sometimes read the value
  with very low counter frequency
- Fix duplicated initializations

- Buttons events source as button property instead of a global one
- Rename events source -> provider for all settings, consistent with the other things like relay and light providers
- AnalogPin to read between a certain analogRead() range
Trying to follow defaults here - analog 'press' is digital LOW, default value is HIGH, so no additional cfg entries are needed besides pin, level and changing evt source
- (debug) Refactor gpio command, add adc to show analogRead(pin)
- (debug) Add button command

Implemented based on:
https://gitter.im/tinkerman-cat/espurna?at=5f5d44c8df4af236f902e25d
https://gitter.im/tinkerman-cat/espurna?at=5f60e7f1f969413294e95370

Simplify fix for:
https://gitter.im/tinkerman-cat/espurna?at=5f6661a1f969413294f7404d

Most of the time, we care about the sum during report interval, not the
value that gets aggregated across all readings

Always do digitalRead() after ISR
Drop trigger, since we can handle this inside of reading routine
(although, pending some changes to make reading interval per-sensor)

Rework read / write through std::atomic

- make sure we call run() before checking for errors, we will miss status update otherwise and lock the sensor class in the error state that it cannot recover from
- set error flag only when either bsec or bme680 report an error. ensure we show any issues reported by the library via the debug log
ref. https://gitter.im/tinkerman-cat/espurna?at=5f63a955c1d1a53705abcbe3
TODO: add custom error messages through virtual method?

Also, a minor fix to the sensors test when using 1m and 2m boards

Device in question: https://www.aliexpress.com/item/32925895199.html
Named after print on the PCB.

Co-authored-by: user176176 <>

- support 32 byte hostname / ssid
- support 64 byte passphrase
- slightly reduce amount of memory allocations
- tweak initialization paths to call persistent(false) as early as possible

Provide safe fallback *only* when char is out-of-range

As it is, numeric 0 was equal to else { ... }, so 00 was never parsed.
Previously, it was assumed that we never try to parse leading / trailing zeroes,
but in turn we also ignored zeroes in the middle of the number...

* Add support for the Zhilde ZLD-64EU-W

This is a power outlet with 6 power sockets and 4 USB ports.

* fixup based on the zld-44eu hw and tasmota template info

Co-authored-by: Maxim Prokhorov <prokhorov.max@outlook.com>

trying to fix #2343
*** [.pio\build\$PIOENV\firmware.bin] TypeError
`expected str, bytes or os.PathLike object, not Dir' trying to evaluate `${__get_flash_size(__env__)}'

as it turns out, PIO platform internals (sometimes) did not use the correct ldscript path

vector will not copy when move ctor is marked noexcept
remove the copy ctor 'trick', re-add dtor. explicitly do the thing we want
(...clang-tidy would've shown this issue, something to do in the CI...)

see 69c65a6a40 (commitcomment-42008295)
Because of the way DHCP is integrated into the Core logic, we need to
call wifi_softap_add_dhcps_lease(...) inbetween WiFi.softApConfig(...) and WiFi.softAp(...)

- magnitudes vector grows by calling copy ctor, ensure filter never gets deleted
- ensure we can't use magnitude member instead of ctor arg
- more magnitude references instead of using index access
- additional checks for isnan, fix report never triggering
- drop event callback. at least for EventSensor, we already have
  report with min / max value change triggers

- BaseFilter must have virtual dtor
- magnitude object is not trivial, we need to manage filter lifetime
- Ensure move also moves filter object
- Clean-up using magnitude object by value in functions

- (experimental) provide generic way to read magnitude values
- expose /api/metrics with values formatted specifically for prometheus, with relay and sensor data
- small tweaks to sensor init

Example config:
```
scrape_configs:
  - job_name: 'espurna'
    metrics_path: '/api/metrics'
    params:
      apikey: ['apikeyapikey']
    static_configs:
      - targets: ['espurna-blabla.lan:80']
```
Where ESPurna side has
```
apiKey => "apikeyapikey"
apiEnabled => "1"
```

plus, hide both under `#if RELAY_SUPPORT`

Ensure we step +1 char into the string
Ensure hex decoding of the payload ignores the separator + number of repeats

* rfb: fix unused repeats setting
* rfb: rename TIMES -> REPEATS
* rfb: use out as first arg

ref. https://travis-ci.com/github/mcspr/espurna-nightly-builder/jobs/378203413#L698

> +env ESPURNA_FLAGS=-DGENERIC_ESP01_512KB ESPURNA_RELEASE_NAME=generic-esp01-512kb ESPURNA_BUILD_SINGLE_SOURCE=1 pio run -e esp8266-512k-base -s -t release
> /home/travis/.platformio/packages/toolchain-xtensa/bin/../lib/gcc/xtensa-lx106-elf/4.8.2/../../../../xtensa-lx106-elf/bin/ld: .pio/build/esp8266-512k-base/firmware.elf section `.irom0.text' will not fit in region `irom0_0_seg'

Remove ~90Kb from the build.

- cache received rfbridge codes in the internal list, allow to operate on it via the rpn operators
- add `<N> <proto> <code> rfb_match`, matching when we receive specified protocol + code string at least N times
- add `<proto> <code> <proto> <code> rfb_sequence`, checking if specified protocol + code pairs happen in sequence
- add `<TIME> <N> <proto> <code> rfb_match_wait` - similar to `rfb_match`, but waiting for at least `TIME` (ms) via oneshot runner
- add `<proto> <code> rfb_info`, pushes code's latest timestamp and it's counter on the stack
- add `<proto> <code> rfb_pop`, which removes the specified protocol + code from the internal cache
- fix MQTT skip setting making RPN variables absent on initial connection
- default to no skip when receiving MQTT
(small issue still stands with us having non-clean MQTT session, broker will persist variable subscriptions even after unsubscribe event)

ref. 6af2bad123
2.3.0 is still not supported, but at least buildable