Replaced the map of tape files with a list as the assumption that we have one copy per copyNb is no more valid with repack.

Modified RdbmsArchiveFileItorImpl.cpp to use autocommitMode default of Stmt::executeQuery() and Stmt::executeNonQuery()

implementation of "cta-admin archivefile ls -all".  A
missing order by clause meant that non deterministic
listings were given.

This commit adds the missing "order by" clause.

Fixed cta/CTA#364 RdbmsArchiveFileItorImpl constructor should NOT return database connection to pool

Moved autocommitMode parameter from Stmt constructor to Stmt::executeQuery() and Stmt::executeNonQuery()

Renamed rdbms::AutocommitMode::ON and rdbms::AutocommitMode::OFF to rdbms::AutocommitMode::AUTOCOMMIT_ON and rdbms::AutocommitMode::OFF respectively

Done

If the whole contents of the ARCHIVE_FILE and TAPE_FILE tables are
listed without a search criteria and with an ORDER BY clause then the
first row back from the database will take a relatively long period of
time to be returned.  This is because the database will have to sort
every row before returning the first.  This long period of time will
cause the current (non SSI) cta command-line tool to time out.

If the "cta af ls" command is executed and the listing
encounters duplicate tape copy numbers then the listing
continues with "workaround" number displayed in place
of the duplicates and inow with this commit a log
message is alseo written to

    /var/log/cta/cta-frontent.log

An example log:

2017-07-12T18:04:40.691236+02:00 itdssbuild01 cta-frontend: LVL="Warn" PID="9423" TID="9436" MSG="Found a duplicate tape copy number when listing archive files" archiveFileID="5" duplicateCopyNb="1" workaroundCopyNb="2" vid="V41001" fSeq="5" blockId="41"