Convert DefaultFileSource and dependents to actor model

[kkaefer]

Getting started on #6426. This is still a work in progress.

A few large changes:

• the DefaultFileSource constructor now takes a Scheduler
• the AssetFileSource does not use its own thread anymore; instead it uses the shared worker threads

Given that our file requests need a way to "cancel" them (i.e. have the callback not invoked, I introduced AssetFileSource::Impl::Request, which holds a shared_ptr to the callback. If that object gets destroyed, the weak_ptr we're passing to the worker thread will be empty, and back on the main thread, the callback obviously can't be fired anymore. I'm not sure if using this violates @jfirebaugh's plea about not using std::shared_ptr with actors (since technically, you could try to lock the weak_ptr in the worker.

I also added a MGLThreadPool object for Darwin, but implemented a global singleton for Android . I believe we should go the global singleton instance for Darwin as well (and remove MGLThreadPool again), since Darwin never deallocates the DefaultFileSource as part of the regular application workflow anyway (it's a singleton in MGLOfflineStorage).

[mention-bot]

@kkaefer, thanks for your PR! By analyzing this pull request, we identified @jfirebaugh, @tmpsantos and @1ec5 to be potential reviewers.

[kkaefer]

The long term goal is to move the other FileSources onto the actor model as well, which enables us to remove util::Thread.

[tmpsantos]

I gave this a shot once and I got stuck. The main problem I faced when removing Thread from the DefaultFileSource was that we need a RunLoop for some platforms on the worker thread for pooling for events. Create a new one for each new request is probably no viable. Also the HTTPFileSource::Impl is usually not thread safe and lives in a fixed thread.

We probably need a new scheduler that is not ThreadPool for the DefaultFileSource at least in some platforms we support.

[1ec5]

This is unnecessary, since there won't be an offline storage object if we're rendering for IB, and even if we were, spinning up this thread pool should be cheap. The reason we do this in MGLOfflineStorage and MGLAccountManager is to avoid potentially expensive operations that may block MGLMapView from rendering within the allotted time.

[1ec5]

No need for a class extension, since the whole header is already internal to the project. A class extension would need to go in a separate header from the public header anyways.

[kkaefer]

Thanks; as per the comment above, I'm planning on removing MGLThreadPool altogether, since it's a singleton anyway.

[kkaefer]

@jfirebaugh given that you're most familiar with this system, could you please do a quick review of whether I'm moving into the right direction with this?

[jfirebaugh]

The way I would model this is to make the request and response callback both first-class actors:

class RequestCallback {
public:
    // This class exists only to accept and ignore the "self" argument. Maybe it should be optional?
    RequestCallback(ActorRef<RequestCallback>, std::function<void (Response)>);
    void operator() (Response response) { callback(response); }

private:
    std::function<void (Response)> callback;
};

class AssetRequest {
public:
    AssetRequest(ActorRef<AssetRequest>);
    ~AssetRequest(); // cancels

    void send(const Resource& resource, ActorRef<RequestCallback> callback) {
        // do whatever, then eventually:
        callback.invoke(&RequestCallback::operator(), response);
    }
};

class SomeClass {
public:
    SomeClass(Scheduler& requestScheduler)
      : request(requestScheduler) {}

private:
    void requestingMethod() {
        request.invoke(&AssetRequest::send, resource, callback);
    }

    void receivingMethod(Response);

    Actor<AssetRequest> request;
    Actor<RequestCallback> callback {
        *util::RunLoop::Get(),
        std::bind(&SomeClass::receivingMethod, this)
    };
};

[jfirebaugh]

Stale.