ath10k-firmware: update Candela Tech firmware images

ath10k-firmware: update Candela Tech firmware images

Release notes since last time:

Release notes for wave-1:

2019-04-02: Support some get/set API for eeprom rate power tables.
	    Mostly backported from 10.2

2019-04-02: Support adaptive-CCA, backported from 10.2

2019-04-02: Support adding eeprom configAddr pairs via the
            set-special API. These configAddrs can be used to change
            the default register settings for up to 12 registers.

2019-05-03: Fix tx-power settings for 2x2, 3x3 rates.
	    Original logic I put in back in 2016 set 2x2 and 3x3 lower
	    than the needed to be when using most NICs (very high
	    powered NICs would not have been affected I think, not sure
	    any of those exist though.)

	    This improves throughput for 2x2 and 3x3 devices,
	    especially when the signal is weaker.

Release notes for wave-2:

2019-04-08: When setting keys, if high bit of high value of
	    key_rsc_counter is set to 0x1, then the lower 48 bits will
	    be used as the PN value.  By default, PN is set to 1 each
	    time the key is set.

2019-04-08: Pack PN into un-used 'excretries' aka
	    'num_pkt_loss_excess_retry' high 16 bits.
	    This lets us report peer PN, but *only* if driver has
	    previously set a PN when setting key (or set-special cmd is
	    used to enable PN reporting).

	    This is done so that we know the driver is recent
            enough to deal with the PN stat reporting.

2019-04-16: Support specifying tx rate on a per-beacon packet.
	    See ath10k_wmi_op_gen_beacon_dma and
	    ath10k_convert_hw_rate_to_rate_info for API details.

	     Driver needs additional work to actually enable this
	     feature currently.

2019-04-30: Compile out tx-prefetch caching logic.
	    It is full of tricky bugs that cause tx hangs.
	    I fixed at least one, but more remain and I have wasted too
	    much time on this already.

2019-05-08: Start rate-ctrl at mcs-3 instead of mcs-5.
	    This significantly helps DHCP happen quickly, probably
	    because the initial rate being too high would take a while
	    to ramp down, especially since there are few packets sent
	    by the time DHCP needs to start.

	    This bug was triggered by me decreasing retries of 0x1e
	    (upstream default) to 0x4.  But, I think it is better to
	    start with lower initial MCS instead of always having a
	    very high retry count.

Tested on 8devices Jalapeno dev board(IPQ4019)

Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com> [neatify]