This fixes the annoying error
```
NameError:
uninitialized constant OrderManagement::Subscriptions::Whatever
```
and let's you execute the spec file in isolation. It slows down way too
much having the run the entire engine test suite while developing. And
it makes me nervous too.
There's a bunch of logging bits we need to find out what happened in
`#5294`, the first of which is logging as we are used to for Rails
itself. Turns out we were already logging but the log lines weren't
displayed.
That's because workers have no access to the Rails logger unless we hack
things a bit in the config/initializer. If we want to keep DJ's logs in
a different file, which I think is good for debugging purposes, we need
to diverge from Rails.logger.
However, there's no access to Delayed::Worker.logger in custom job
classes either so there's no way other than mimicking that logger's format
if we want log lines to be consistent.
Now the current logs will see the light like:
```
2020-05-07T14:09:42+0000: [Worker(host:8dc5e7e6f434 pid:1)] Job SubscriptionPlacementJob (id=54) RUNNING
2020-05-07T14:09:42+0000: Placing Order for Proxy Order 1
2020-05-07T14:09:42+0000: Issue in Subscription Order 2: complete
2020-05-07T14:09:42+0000: Placing Order for Proxy Order 7
2020-05-07T14:09:42+0000: Issue in Subscription Order 3: complete
2020-05-07T14:09:43+0000: [Worker(host:8dc5e7e6f434 pid:1)] Job SubscriptionPlacementJob (id=54) COMPLETED after 0.3378
2020-05-07T14:09:43+0000: [Worker(host:8dc5e7e6f434 pid:1)] 1 jobs processed at 2.8054 j/s, 0 failed
```
We'll see if we need to format these messages differently to make them
more greppeable.
This makes things a bit simpler in terms of routing, we avoid a problem running specs and we can still have the engine routes separated in specific files
Also, add a missing . to card_set? that eanbles it! If the card was
already set, it would anyway set the default card. Now it will use the
defined card if there is one already.
Right now and for some time the engines are not independent of the main_app. We should aim for that but it will naturally take a while to disentangle the code
The calculators of the adjustments related to the enterprise fees
created in the test setup have a preferred_amount of 0. So, when
computed, the adjustments' amounts end up being `0 = 0 * 1 line_item`.
Then, the ReportService filters these out in
`#exclude_groups_with_zero_total` from the result set. This is why the
assertions can't find them in `totals`.
