Refactor and simplify .deb build steps in Drone CI config (duplicate of #1700 for develop-5 branch)

[ottok]

This makes the current Drone CI build .deb partspass and also simplifies
the config so that future maitenance of it will be easier and less error
prone. The mcs39_select_limit test failure still remains for .rpm.

Also remove autobake-deb.sh as it is unfit for this git repository.

The debian/autobake-deb.sh is designed as a build system for the MariaDB
Server that automatically adapts the build dependencies according to each
platform the MariaDB Server supports.

This is not in any way designed or fit for use with ColumnStore. It was
copied to this repo in commit 68f15c9 without any motivations on why
and accoring to Roman it was just a temporary thing that is safe to
remove.

[ottok]

@drrtuy @mariadb-RomanNavrotskiy Please merge.

[ottok]

@drrtuy @mariadb-RomanNavrotskiy This is for develop-5 branch, please merge?

[ottok]

Could you please review and merge this?

[drrtuy]

Looking at autobake-deb.sh I see that there are two points we'll loose droping TRAVIS flag:

• BUILDPACKAGE_FLAGS="-b"
• according with autobake logic our CI will now produce a prolonged list of packages contents that we also would like to avoid.

How would you suggest to add these two not using TRAVIS?

[ottok]

@drrtuy Rebased on latest develop-5. Added BUILDPACKAGE_FLAGS="-b". The lines from line 300 onwards already move most of the excess stuff you don't need for the ColumnStore CI.

Please merge.

The goal for the ColumnStore CI is to catch regressions in the ColumnStore code. It should run as quickly as possibly, and avoid building excess stuff, like most of the server (although the exact needs and dependencies of ColumnStore are still undocumented). You need to have in the ColumnStore codebase a file you can modify to slim down the build until you find the optimal scope, building ColumStore only and nothing else. You should not rely too much on autobake-deb.sh from another repository. Such an external relation will cause problems down the road as you need to update two repos in parallel, and anybody who updates the MariaDB Server sources alone will not see ColumnStore CI failures.

What I've done now is a step in the right direction. The ideal situation would be a fully standalone build, which I made some drafting for in PR#1701

Also, I would recommend you deploy "protected branches" feature in GitHub to prevent that your develop / develop-5 branches can never again get in a state that the CI does not pass, as people could simply not push/merge on them unless their commit passed the CI.

[drrtuy]

I am 100% with you speaking about an external dependency on autobake. However this direction became less important after we initially converged with the server and that was a mistake. Because of that I would like to thank you for highlighting this once again.
I am not aware that it is possible to build rocksdb or sphinx packages w/o building the server. Is it really possible?
We protect the main branches with a mandatory review so the merge must not happen before CI converges. Unfortunately this rule is violated sometimes.