Don't stop install process if mysqld fails to start (dpkg)

As the final step of dh_installinit, dh tries to start the mysqld server
after installing the init script to /etc/init.d/. If the server fails to
start for any reason (for example a buggy my.cnf), dpkg or apt-get report
a failed installation, which does not reflect what really happened,
creating some confusion.

Fix this by appending --error-handler=: to dh_installinit, effectively
ignoring if the server was able to get started or not -- since this
doesn't really affect the installation process.
Don't stop install process if mysqld fails to start (dpkg)

Merge fix for bug #1002500 from 5.1
Automerge prerequisite branch
Automerge prerequisite branch
Fix
- bug 1191580 (InnoDB: Failing assertion:
  bitmap_files->files[0].seq_num == first_file_seq_num in file
  log0online.cc line 1423 | abort in
  log_online_setup_bitmap_file_range);
- bug 1191589 (mysqld-debug: .../sql/protocol.cc:518: void
  Protocol::end_statement(): Assertion `0' failed on a
  INFORMATION_SCHEMA.INNODB_CHANGED_PAGES query). 

The issue is bug 1191580 is a race condition between the two bitmap
file enumeration passes in log_online_setup_bitmap_file_range().   If
the 1st bitmap file in the range is deleted at that point, then the
debug build will crash as reported on this bug.  For release builds
this is not an issue as the missing bitmap file will be detected and
diagnosed on an attempt to open it, as fixed by bug 1179974. The
current bug shows that the fix for the latter was incomplete.

Fixed by adjusting the range check code in
log_online_setup_bitmap_file_range() to check for the above condition,
print diagnostics, and return range setup error.  Since these
diagnostics are now printed in two places instead of one, pull it out
to a new static function log_online_diagnose_inconsistent_dir().
Adjust it to print "Warning" instead of "Error" as it's not a fatal
issue.

At the same time fix bug 1191589.  The issue there is that on
log_online_bitmap_iterator_init() failure (such as bug 1191580), the
error is not returned to client properly.  Fixed by returning
ER_CANT_FIND_SYSTEM_REC there and also for a
schema_table_store_record() failure.

At the same time take a related bug 1204075 fix from XtraBackup.

Add a testcase, common for both bugs, to
percona_changed_page_bmp_debug.test.
Merge bug 1191580 and bug 1191589 fixes from 5.1.
Add entry into debian changelog for last commit
Add entry into debian changelog for last commit
Bugs fixed: Bug #1210549 and Bug #1206069
Bug 1204873: Valgrind: bytes lost in operator new[] | Table_node::Table_node
Memory allocated for array or Column_node pointers were not deallocated in
Table_node destructor because Sql_alloc doesn't invoke destructor when
releases memory. It means that classes inherited from Sql_alloc must not
use destructor for memory deallocation.
Automerge lp:~laurynas-biveinis/percona-server/bug1191580-1191589-5.5
Merge lp:~hrvojem/percona-server/bug1206069-5.5
http://jenkins.percona.com/job/merge-PS-5.5-docs-kickoff/45/
Fix generated cmake/install_layout.cmake in SRPMS when cross-compiling

When cross-compiling to i686 with build-rpm.sh with the --i686 switch,
build-rpm.sh would patch cmake/install_layout.cmake moving the lib64/ dir
to lib/, as it should be for the target 32 bit platform. The rationale
behind this is that the library directory name (lib64 or lib) is
determined by the CMAKE_SYSTEM_PROCESSOR cmake variable, and there's no
documented way of altering this variable (setting it with -D doesn't
work), so when cross-compiling the libraries would get installed to
lib64/ anyway.

The problem was that this was done prior to creating the source .tar.gz,
so the sources that went into the SRPM would be patched, potentially
creating problems if later this SRPM was used for creating 64bit binaries
(bug #1174300).

Fix this by moving the patching logic to percona-server.spec, where the
cmake/install_layout.cmake is patched after uncompressing from source.
Automerge lp:~ignacio-nin/percona-server/5.5-bug1002500
Automerge lp:~sergei.glushchenko/percona-server/5.5-ps-bug1204873
Automerge lp:~ignacio-nin/percona-server/5.5-bug1174300
Bugs fixed: Bug #1229583, Bug #1098360 and Bug #1207644
Bugs fixed: Bug #1229583, Bug #1098360, Bug #1207644, Bug #1223197 and
Bug #1182098
Fix for https://bugs.launchpad.net/percona-server/+bug/1166638 - Utility user setup leaks memory | Valgrind: still reachable: malloc in acl_init_utility_user & init_dynamic_array2

Originally this was just written off as a known, one time leak, which is is, but the failure causes scripted testing to fail and is really just sloppy.

To fix, created new status flag that indicates whether or not acl_utility_user and acl_utility_user_schema_access have been initialized. Create new function to clean up utility user resources and call it from acl_free and from acl_init_utility_user to free up if being reinitialized or if there is an error during the initialization.
Automerge lp:~gl-az/percona-server/BT-23597-bug1166638-5.5