Merge freephile:34.x into enterprisemediawiki:34.x

[freephile]

Changes

The 34.x branch was based on the enterprisemediawiki:32.x branch. The 34.x branch is still a work in progress, but is close to being ready for use. This brings several enhancements, notably:

1. MediaWiki REL1_34
2. updates to all extensions that use that branch
3. updates to Elasticsearch to 6.x (for new installs) 5.x for existing installs
4. updates to PHP to 7.2
5. updates to MariaDB to 10.3.22 (for new installs) ... and MariaDB 10.4 is planned
6. automatic certificate provisioning using Certbot
7. pretty URLs
8. and more

Issues

• Closes #748

Post-merge actions

Post-merge, the following actions need to be addressed:

• [ ] launch or configure for automated tests against this branch
• [ ] Review test results and fix issues as needed
• [ ] Update documentation at https://www.mediawiki.org/wiki/Meza

[jamesmontalvo3]

@freephile @revansx thanks for putting this together. I've largely taken a hiatus from Meza until recently, to focus on some other projects. My plan has been to come back here and put together a release for the next MediaWiki LTS, v1.35. COVID-19 has delayed that release until probably August, so here's my plan going forward:

1. MediaWiki branch REL1_35 will be cut from master sometime in July. To get to work now, and rather than trying to track master day-to-day, instead I plan to declare an arbitrary commit on master to be the REL1_35_pro_tem. What commit Meza points to can then be advanced forward as necessary, but won't change multiple times per day as WMF modifies MediaWiki (making it hard to track issues with Meza vs MediaWiki).
2. Travis CI has gotten slower to pick up new jobs. I've often waited 5-30 minutes for the jobs to start after making a commits recently. As such, I'm experimenting with running builds elsewhere. This is a prerequisite to getting any real work done, because waiting for tests to complete is just too much of a drain on development. Ref #1259.
3. I need to cross reference enterprisemediawiki/master, enterprisemediawiki/32.x and freephile/34.x and determine what should go into enterprisemediawiki/35.x (and ultimately master ASAP). There are some changes I see here that will not be accepted into EMW, namely:
   1. Setting inexact Composer extension versions like ~3.1 instead of 3.1.0. Surprise changes have bitten us too many times when an extension author incorrectly decides that 3.1.1 is a non-breaking change over 3.1.0. There are some extensions that track REL branches, but these are mostly WMF-managed extensions which are more stable. Even these, though, would ideally be exact.
   2. Cannot manage multiple versions of Elasticsearch. Meza should either be 5.x or 6.x, not one or the other depending on when you initially installed.
   3. The following will not be included in the initial 35.x branch, and should be broken into separate PRs to be discussed/assessed on their own merits. The 35.x PR will likely be difficult enough to get merged without unrelated items.
      • Lets Encrypt (love this addition, just needs to be separated and tested properly)
      • Short URLs and Subdomains (I like these too, but past implementations have died in PRs because they didn't work in all cases and weren't tested)
4. Some other considerations:
   1. I'm not sure about the addition of goaccess for the same reason as not forcing WatchAnalytics on people. It should be optional if it is included. Also, don't we already have Netdata? I'm not familiar with goaccess. Benefit of one over the other?
   2. PHP should be 7.4 if possible, so it doesn't go EOL before the next MW LTS (1.39 in spring 2022, and I think PHP 7.4 EOL is late 2022 or so). This is not a show-stopper. If there are issues with 7.4 we can do 7.3 or 7.2 if required.
   3. While removal of EMW extension (Wiretap, WatchAnalytics, etc) may be the right decision, thus allowing users to choose their extensions, Meza still needs to be made to support EMW-specific extensions.

[freephile]

Welcome back @jamesmontalvo3 ! These all sound like great feedback and news. I'll be looking to make commits more merge-ready.

[freephile]

1. I'm not sure about the addition of goaccess for the same reason as not forcing WatchAnalytics on people. It should be optional if it is included. Also, don't we already have Netdata? I'm not familiar with goaccess. Benefit of one over the other?

I was experimenting with packages that provide traffic analytics (v. monitoring). Matomo is a much better option than GoAccess for Web Analytics. It's inclusion should / will be made optional.

[jamesmontalvo3]

@freephile @revansx see #1265.