Copter: fix inconsistent setting of AP_Notify::flags.pre_arm_gps_check

[peterbarker]

Some clauses in here were not resetting the notify flag. So we assume failure and fix it when we've been overly pessimistic.

[WickedShell]

Does notify only update when called from the main loop, or are there any timers that are spawned that directly read the flags? (If so I'd be worried about race conditions causing notify to momentarily show failure).

[peterbarker]

@WickedShell AFAIK it all happens on the main thread. We'd be on thin ice if it didn't with the data structures used in AP_Notify!

[WickedShell]

@peterbarker I wasn't sure if that was a promise we had before (I haven't seen the set failed then fix if not true assumption used elsewhere which is why I was raising the question).

[peterbarker]

On Mon, 25 Jun 2018, WickedShell wrote: @peterbarker I wasn't sure if that was a promise we had before (I haven't seen the set failed then fix if not true assumption used elsewhere which is why I was raising the question).

I'm playing around with the concept of setting all of the AP_Notify stuff in one place - it would be in the caller of this function, so the set-to-false-then-prove-otherwise thing would go away. But I thought it worth fixing this apparent bug in a separate PR.