Dmtm

передать в адаптер обработчик действия

setMyChangeDataCallback(ISomeKindChangeDataCallback callback),

в адаптере на

onClickLister() { ... callback.doChangeData(int param1,....); }

реализация обработчика во фрагменте

ISomeKindChangeDataCallback callback = new ISomeKindChangeDataCallback() {
void doChangeData(int param1,....) {
//если данные уже есть то
      adaper.setData(новые данные).doRefreshNowAndImmediatelly();
//иначе запросить данные
}

почему запросы выполняются в контроллере а не в самом CompletableFuture?
примерно так:
CompletableFuture.supplyAsync(...)
.exceptionally(....)
.thenApply(....)
.thenAccept(....);

вместо того чтобы закрывать приложение не лучше ли предварительно проверять есть ли интернет?
до попытки загрузить что-то

лучший способ работы с базой данных - через ORM (ORMLite, greenDAO и кто там сейчас есть еще)
и для 99% случаев это будет родная sqlite,
но никто не мешает добавить что-то стороннее, тут можно посмотреть на различные встраиваемые базы,
типа HSQLDB - берем jar и добавляем в проект,
но зачем?

очевидно сделать разную сигнатуру?
просто обернуть исходный фрагмент:
Fragment1 extends CommonFragment
и
Fragment2 extends CommonFragment
и в эвенте передавать класс с параметром кому

сериализация в json (чтобы не писать конвертер самому), хранить как строку

если "максимально простое решение" это без библиотек, то
это запросы в Thread, Thread хранить в Application, дата слой - синглтон также с привязкой к Application
дата слой - мап вида <url, object>где object - десериализованный ответ
бродкасты для отсылки сообщений о результатах запроса (если не хочется возиться с бродкастами, то есть EventBus)

т.е. запрос меняет данные, дата слой оповещает об изменении, потребитель сам забирает данные

для простых проектов сойдет, но потом начнутся сложности
типа атомарность бизнес операции состоящей из нескольких запросов (привет RxJava) или сохранение состояния экрана (в т.ч. с динамическими view) - (привет Moxy), даже просто дождаться появления интернета и заново выполнить запрос из очереди - все самому писать придется

асинктаск не предназначен для запросов, где-то даже в документации об этом упоминалось,
потому что асинктаск живет до первого поворота экрана,
используйте Thread

все классы наследуются от Object,
Object variable

Поддерживать то что есть и так как есть. Попутно слегка рефакторить (типа переменные правильно назвать, лишний код вычистить - не больше). Быть готовым к увольнению и уже сейчас начинать искать новую работу.

Scala / Kotlin / Clojure

все это конечно интересно и занимательно, а кто проект будет потом поддерживать?
ни один вменяемый ПМ/лид/заказчик не выберет эту экзотику для энтерпрайза
из фреймворков конечно же только Spring или чистые EJB

Как можно организовать такую передачу?

независимый от UI слой данных (если по быстрому то переменные в Application) и не надо никакого Parсelable,
через бродкаст только уведомление об изменении, ответы сервера пишутся в Application,
потребитель получает уведомление и берет их там, если не получает а только что был создан - все равно берет их там
PS: я бы использовал просто Thread с бесконечным циклом для запросов и EventBus для уведомлений
PPS: ListView умер, только RecycledView
PPPS: по идее, где реальное время - там сокет? а не запросы

"а зачем вы используете С++ вместо языка программирования?"

Хотелось бы писать программы с графическим интерефейсом

- десктоп приложения умерли еще в прошлом веке, а игры уже давно на C# и даже на яве, драйверописателей нужны единицы, даже представить не могу где может цпп понадобиться?

я бы сделал общую очередь (Deque) запросов, FIFO,
ждущий исполнитель запросов, забирает задачи из начала очереди, активируется при попадании очередного запроса в очередь,
настраиваемый пул потоков для распараллеливания
при желании можно добавить валидацию запросов и например, не прошедшие - ставить в конец очереди (почитать про poison request messages)

одно время присматривался к puppyrus.org

нужен слой данных, независимый от UI,
UI берет данные только в data layer
EventBus рассылает только уведомления об изменении в данных, но не сами данные
т.е. если активность живая, то она берет значения в data layer по умолчанию, если во время жизни приходит уведомление, то обновляется из data layer,
если же активность перезапустилась, то уведомление конечно пропало, но данные все равно берутся из data layer

все верно, rxjava не решает основных проблем с жизненным циклом, бесполезная вещь,
пока не знаю ничего лучше очереди задач (BlockingQueue), пула потоков (Thread) и EventBus

"Какая асинхронность??? - если её в принципе в Activity и Fragments не должно быть?"
Как это не должно быть? Скорее - наоборот, любой качественный UI должен быть асинхронным, то есть все тяжелые операции - в потоке, отдельном от UI.

вот поэтому UI (слой View) не асинхронный, асинхронные операции вне Activity и Fragments