Add support for additional mu-plugins

[mjangda]

This change allows sites to add a client-mu-plugins folder (open to name change) in their VIP Go repo, which we load similar to mu-plugins. The client mu-plugins are loaded after the VIP Go mu-plugins are loaded ("enforced" by the filename prefix).

As part of this change, we will probably need a few others:

• Update vip-go-skeleton to include the folder.
• Update vip-go-api to make the new folder required on site init.
• Update vipd to map the folder inside wp-content within web containers.
• Update docs (https://vip.wordpress.com/documentation/vip-go/local-vip-go-development-environment/)

We will also probably need to re-create web containers for any sites that want to use this.

See #166

[mjangda]

/cc @mikeselander

[joshbetz]

Presumably this is so files load in a predictable, alphabetical order instead of whatever order they happen to appear on the filesystem?

[mjangda]

Yep. Probably worth an inline comment.

[mjangda]

Added comment.

[joshbetz]

I think we need to call this function somewhere?

[mjangda]

Heh, good catch. Fixed.

Addressed feedback

[mikeselander]

Thanks for writing this up and pinging me @mjangda - really appreciate the responsiveness on this request!

[CodeProKid]

What's the status on this? Would love to start leveraging this.

[mjangda]

Thanks for the ping @CodeProKid. This fell off our radar a bit but hoping to get it ready soon.

[mjangda]

vip-go-skeleton update in Automattic/vip-go-skeleton#14

[mjangda]

vipd has been updated to map the directory inside web containers.

[mjangda]

r94201-deploy

[mjangda]

We're going to hold off on the vip-go-api update until we've added the folder to all existing repos/branches.

[fklein-lu]

I question the way that this feature was implemented:

• Is there a need to define a global constant for the client MU plugins directory? The preference should be not to place more elements in the root namespace if it can be avoided.
• Why define a function if it is invoked only once, immediately after its definition, and if the function contains protections against being called more than once? This code is not meant to be run more than once, so it shouldn't be placed in a reusable element.
• By including the MU plugin files inside of a function, variables defined inside in these files are not placed in the global scope, but are restricted to the scope of the function. This behaviour differs from regular MU plugins.

The preferred approach should be to write this as a script:

• No need for constants or functions.
• Variables defined inside of MU plugins will be put in the right scope, without needing to do any of the awful things that wpcom_vip_load_plugin() does.
• MU plugin files only get loaded once, so there's no need to protect against the client MU plugins being loaded multiple times.
• You can use temporary variables, and as long as you unset them at the bottom of the script, they won't pollute the global namespace.

[mjangda]

Thanks for the feedback, @fklein-lu, especially the point about scoping. The remaining points are somewhat subjective (e.g. putting the logic inside a function would allow us to more easily add tests) but will take them into consideration as we work to fix the scoping issue.