Wireless Mobility Connections Fail and Do Not Recover When ASA is Rebooted

I saw this issue for the first time today so I thought it was worth sharing. 
Full article is linked here: LINK

Took TAC a while to find the issue, but apparently TAC says its a design issue not a bug.

Brief overview:

Problem

In this situation a Wireless LAN Controller (WLC) at 10.10.1.2 attempts to communicate with the WLC at 10.10.9.3, but the communication fails.
This problem can be triggered by any of these events:

• The ASA is rebooted.
• The routing table is modified by an administrator or routing protocol.
• An interface is shut down, then brought back up by the administrator.

Besides mobility traffic, this problem might be experienced for any UDP or non-TCP IP protocols.

Solution

Solution 1

One possible solution for this issue is to remove the same-security permit intra-interface command from the ASA. This solution prevents the u-turn connection from being built back out the same interface on which the original packet was received, which allows the correct connection to be built when the interface comes up. However, depending on the routing table of the ASA, this solution might not work (the traffic might be routed to another interface other than the intended destination based on the routing table), and the same-security permit intra-interface command might be necessary for other connections on the ASA.

Solution 2

For this specific instance, the problem was successfully mitigated by enabling the timeout floating-conn feature. This feature, which is not enabled by default, caused the ASA to tear down these connections one minute after a more preferred route to one of the endpoints is added to the routing table out a new interface of the ASA, which occurs when the dmz interface comes up. The connections are then immediately rebuilt when the next packet arrives at the ASA, using the more preferred interface (dmz, instead of inside for the 10.10.9.3 host).

ASA(config)# timeout floating-conn 0:01:00