Buildbot steps added in the scope of this task are listed below. All steps are run under if do_package python condition, after package creation/publishing, before MTR tests.

• set property package_bits
  It's an auxiliary step. We need to know whether it's a 32-bit or 64-bit installation later on in a few places.
  It uses the name of the builder and sets 64 for winx64-packages and 32 otherwise. So, besides being a bit cumbersome, it also depends on the builder name, which is not optimal. There are other ways to get the same information, it was the least invasive at this point. The more invasive but possibly more sustainable way could be to pass the bit-ness as a parameter to make_win_build_factory, possibly instead of generator, and then generate the generator name accordingly (with Win64 for 64-bit and without it otherwise). I didn't do it, because I'm not sure whether the builds can be run with essentially different generators at the same time (it's not the case at the moment, all builds are run with Visual Studio 15 2017).

• set property program_files_dir
  It's an auxiliary step. We need to know where to find the installed binaries later, as it depends on whether the build is 32-bit or 64-bit. Unfortunately, %ProgramFiles% doesn't work well with buildbot, first because it doesn't like Windows variables in general (it tries to interpret them as properties), and secondly because there appears to be inconsistency in how Windows (or more likely dojob in buildbot) handles paths with spaces. In some cases, it wants it in the form of C:\"Path with spaces"\etc, while in other cases it wants it as "C:\Path with spaces\etc".
  The step exists twice in the config, instances are mutually exclusive: one is for 64-bit only, another is for 32-bit only. In this case it's simpler than conditioning inside the command line.
  If we make bit-ness a python function argument instead of a property, then this value can be set in python code itself instead, and the step can be eliminated.

• cleanup_64bit_msi / cleanup_32bit_msi
  The step calls wlad's cleanup script, to forcefully remove existing installations in case previous tests went wrong. The 32-bit and 64-bit steps are mutually exclusive, the difference is a command-line switch which is only passed for 64-bit version.
  If we make bit-ness a python function argument instead of a property, then the switch can be set in python code to either -x64 or an empty string depending on the bit-ness, and the step use it, in which case there will be no need in separate steps.

• install-msi
  The step renames the existing .msi file into either mariadb-64.msi or mariadb-32.msi (because we don't know the exact name of the msi, and msiexec doesn't appear to resolve wildcards). It assumes there is only one msi file after the build, if it ever changes, things can break.
  The it runs msiexec under start, to make sure it runs in the foreground, otherwise msiexec exits immediately and the installation continues in the background.
  It installs the package with either MariaDB-64 or MariaDB-32 service name and either 3364 or 3332 port. INSTALLDIR is unconditionally set to C:\Program Files\MariaDB, because the distinction between Program Files and Program Files (x86) is made automatically by the system.
  The step provides the installation log as msiexec_log. However, further we have to use the previously set program_files_dir property to find the installation.
  It runs under the same conditions as package creation.

• check-msi
  The step first checks that the built mysqld.exe binary (the one in sql\RelWIthDebInfo) and the installed one are identical. Checking just the version wouldn't be enough for intermediate builds, as there might be a previous x.y.z installation on the machine while the next x.y.z installation is attempted. And we can't check the revision in the binary, as the variable doesn't exist in all supported versions.
  Then the step runs mysql client from the installation to connect to the server which is expected to run, and executes a couple of basic select/show queries. It can be further extended if needed, but then we'd probably have to move it into a separate script.
  It runs under the same conditions as package creation.

• uninstall-msi
  The step runs runs msiexec under start to remove the installation. It relies on the exit code produced by msiexec. Possibly we need to consider a better detection of whether the deistallation did the job.
  It runs under the same conditions as package creation.