This is a follow-up to BF-22891. It seems that this is actually a classic engine bug and SERVER-60588 will permanently fix the issue, but we want to write a test to see if there are any other bugs in SBE's implementation of $multiply that we don't know about. We should be able to run this test in both the classic and SBE engines and get the same results.

We could try calling $multiply with 2 args and 3 args with every possible combination of types. We should test very small and very large values: 1, 2^32, 2^32-1, -1, as well as the limits of each of the types that may cause an overflow.

Here's a repro of one failure, the one that occurred in the original BF:
> db.fuzzer_coll.drop();
> db.fuzzer_coll.insert([{_id: 13}, {_id: 14, num: 1}]);
> db.fuzzer_coll.aggregate([{$sort: {_id: 1}}, {$limit: 20}, {$graphLookup: {from: "fuzzer_coll", startWith: {$filter: {input: "$array", cond: {$or: []}}}, connectFromField: "nonexistent", connectToField: "nonexistent", as: "array", restrictSearchWithMatch: {$expr: {$multiply: ["$num", NumberLong("314159265358979393"), NumberLong("-314159265358979323")]}}}}]);

In the v5.1 shell, this results in:
{ "_id" : 13, "array" : [ { "_id" : 14, "num" : 1 } ] }
{ "_id" : 14, "num" : 1, "array" : [ { "_id" : 14, "num" : 1 } ] }

In the v5.0 shell, however, it triggers an error: "Can't coerce out of range value -9.8696e+34 to long."