Задача# Что дано

Есть приложение, в котором уже есть некоторые акторы и определено
некоторое простое REST API.

* TickerActor - актор, срабатывающий раз в секунду и отсылающий задание в LinksActor
на чтение очередного url. Это специально сделано так, чтобы нас не забанили за слишком
частые запросы

* LinksActor - менеджер ссылок. Управляет знанием о том, какие ссылки посещены, какие поставлены
в очередь. В реальной жизни он бы хранил свое знание каким-то персистентным образом.
Но мы для простоты будем это делать в простых коллекциях.

* ClientActor - актор, отвечающий за вызов функциональности spray-клиента

* ServerActor - актор, отвечающий за функциоеальность spray-сервера

# Что хотим

В целом - сделать акторное приложение для краулинга русского раздела википедии.

В частности (я предполагаю, что обходить граф в ширину все уммеют):

* разовьем интерфейс и поведение LinksActor. Пусть он

** хранит очередь известных, но непосещенных путей и множество посещенных

** принимает сообщение AddPaths со списком путей-кандидатов, отбрасывает уже посещенные,
а остальные добавляет в очередь и в множество посещенных

** по PickNext берет путь из очереди и шлет Download в ClientActor

** адекватно отвечает на запрос о статистике

Это 5 баллов из 20

* разовьем поведение ClientActor

** Получив ответ и убедившись, что это корректный ответ (код 200), пошлем текст
в новый ContentActor

** В случае проблем сообщим о них в IssuesActor. Отдельно обработаем ситуации отсутсвия соединения,
ситуацию неуспешного кода и неожиданного типа контента. Будем считать, что все кроме text/html
для нас неожиданно

Это 5 баллов из 20

* создадим IssuesActor

Пусть у него будет три сообщения на три типа проблем (см. выше). Реакция - логирование (akka-логирование)
и подсчет проблем трех типов.

Это 2 балла из 20

* создадим ContentActor

** Добавим в проект внешнюю библиотеку bsoup (найдем ее в мавен-репозитории, добавим в build.sbt)

** Научимся принимать сообщения от ClientActor

** Будем хранить словарь, отображающий путь на сырой html

** С помощью bsoup будем находить ссылки, отбрасывать ссылки, ведущие за пределы индексируемого ресурса
и слать сообщение в ClientActor

** при ошибках парсинга информировать IssuesActor. Там появится четверный тип проблем

Это 5 баллов из 20

** Добавим в серверу новый путь - /issues. Ответом будет json, с 4 полями, в каждом из которых - количество проблем
каждого из 4 типов.

Это 3 балла из 20

# Требования и советы.

Нельзя использовать глобальные структуры.
Например, завести глобальный ConcurrentHashMap.
Все данные должны быть инкапсулированы в
акторы, ответственные за них.

Допускается локальная мутаельность. То есть можно сделать мутабельную
структуру и менять ее в акторе.

Конкретные интерфейсы акторов - на ваше усмотрение.

Часто одному актору нужно знать о других акторах.
Это можно решать двумя способами: или
указывать акторов-пертнеров при инициализации, или
передавать ActorRef через сообщение.
Выбор способа - на ваше усмотрение.

# Практические замечания

В реальной системе мы бы, конечно, усложнили обработку текста.
И, скорее всего, мы бы завели, отдельные акторы, котор