ICAT performance improvements provided by Thomas Ledoux, adding 
'limit 1' when one row is expected (Postgres or MySQL).

These changes add a 'limit 1' string to SQL being run from ICAT
functions in which only one row should be returned which, in some
cases, can significantly improve performance.  Thomas found this
analysing a findAVU call which took several minutes on his large
Postgres instance but with this change took only 36ms! In addition to
that, this change applies to other cases where one row is expected so
there are likely other performance improvements as part of this.

I believe this is safe as the ICAT code is expecting one row and if
something is wrong and multiple rows are returned, it will discard
them anyway.  So the 'limit 1' should do no harm.  In the local
testing I've done (mostly 'devtest') everything still seems to work
fine.

In general, one wouldn't add 'limit 1' in a case like this because it
may be a bit unclear (a reader might wonder why the SQL writer needed
to limit the results to only 1).  But apparently, the DMBS (at least
Postgres) uses this to return once a result is found (reasonably
enough) and so can be much faster.  In local testing on a very small
instance, there is no noticable slow-down using 'limit 1' so it is
likely preferrable in all cases.

Oracle does not support 'limit' but uses a 'where rownum <' construct
so it would need to be done differently and I'm not sure it would be
faster (probably is though).  So this update does not change Oracle
SQL.

This has been tested with Postgres but has not yet been tested with
MySQ (it will later tho and should be fine).

Thanks to Thomas Ledoux of the French National Library for this.
(These are largely Thomas' updates with a couple minor changes made by
me.)

See the irod-chat thread 'Heavy selects for findAVU' for more.



git-svn-id: svn://irodssvn.ucsd.edu/trunk@5418 ea137bd6-aa86-47b6-b90d-b101d9f19a90