Handling connection loss

I've been sufficiently annoyed by Josh's discovery that the
reconnection changes in 1.14 are still broken in some situations that
I've spent most of the day hacking on this. It's become pretty clear
to me that the current code structure really doesn't lend itself to
cleanly handling all possible disconnection scenarios - every time I
managed to fix one potential problem area I found another - and then
realised that I was building connection handling code into all sorts
of unrelated places where it really shouldn't be.

So, I bit the bullet and moved all the reconnection code into the low
level database classes. Originally I shied away from that due to the
need to throw up message boxes, but I'm pretty much convinced now that
that is the lesser of the evils. So, the attached patch (against
REL-1_14_0_PATCHES) centralises the connection test code into on
function in pgConn:CheckConnection, which will check the connection
and allows the user to reconnect if desired. All the other pgConn
functions that use the database connection (except those doing the
setup) now call that function upon entry, as do most of the places in
other parts of the app that used to do some form of connection
checking.

The one downside to this design is that failure to reconnect
constitutes a fatal error, as there's no way from the low level
database classes that we can cleanup state in the higher levels. It's
not quite as bad as it initially sounds though - the user can request
infinite connection retries; it only exits when they hit "No" to the
reconnect prompt (which is clear that doing so will be fatal).

I'm proposing this for 1.14, however I'm aware it's a big change, and
it's late in the cycle. I'd therefore like lots of review and testing
please :-)

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company