Fix admin products publication slowness

[aldeed]

Resolves #4040
Impact: minor
Type: performance

Issue

Logging in as admin and going to grid / loading med/larg devtools dataset would cause browser to hang due to crazy admin "Products" publication

Solution

This solves the issue WITHOUT revision control, i.e., only for 2.0.0 release track. It may be solvable in 1.0 track, but revisions adds a layer of complication. Let's get this merged and then figure out whether it is worth trying to fix in 1.0

I also added two relevant indexes in the Products schema.

This also includes the changes from #4256 and #4259

Breaking changes

None.

Testing

1. As admin, with 1000+ products.
2. On product grid home, it loads within a few seconds and does not hang.
3. On product grid for tag, it loads within a few seconds and does not hang, and is filtered correctly.
4. Test above with and without edit mode. In edit mode, you should only see products for shops for which you have "createProduct" permission (in marketplace setup).
5. Test any other grid filtering you can think of

[pmn4]

@aldeed I have been working on a change to the same code to ensure that Marketplace Shops only see their own products. Do you mind taking a look?

[aldeed]

@pmn4 I looked at your code while doing this and made the same changes in this PR. This is for 2.0 track. Your PR code looked good to me, but I see that you've made some more changes today. I can take another look.

[pmn4]

thanks @aldeed.
there are two PRs, the one you referenced (which ensures that admins see only the shops for which they have edit rights) and the second (which limits products to either a) all active shops if the current shop is the Primary Shop, or b) the current shop's products if the current Shop is a Merchant Shop)

[brent-hoover]

still pretty slow when loading Tag pages but 1000X better than the current version which just crashes my browser and the server.

[brent-hoover]

This seems an odd thing to add to this PR. And just a little odd in general. Is that on purpose?

[aldeed]

The changes I made seem to have changed the order in which Meteor runs the tests, and a bunch of them started consistently timing out on my machine and PR. I think the timeouts happen for whatever tests run first, because often the startup code (mostly migrations) is still running and ends up slowing down how fast the db ops in tests happen.

It seems like Meteor should have some better solution, like allowing us to indicate when startup code is done, and then starting the test run. Maybe if we moved the migrations and other things into Meteor.startup blocks? But anyway, bumping up the timeouts on every test that failed seemed the quickest way to unblock this.