Тут нужно понять такую идею, что ресурс - это неотъемлимая часть программы, которая должна существовать для ее нормальной работы и именно поэтому помещается в resources и существует внутри одного jar-файла. Если эти файлы убрать из jar, то они перестают быть "ресурсами", а становятся обычными файлами в файловой системе и работать с ними нужно соответственно - через пакеты java.io/java.nio условно

Смысл есть, когда вы пишите аннотацию для аннотаций и необходимо применять ее и к самой аннотации. Самый яркий пример - @Retention и @Target. Для самих @Retention и @Target аннотаций они тоже необходимы, т.к. применяется к аннотациям. Вот такая рекурсия. На практике же крайне специфичный кейс

Добрый вечер!
В контроллерах getDefer1, 2, 3 вы блокируете поток томкета, правильнее будет переделать на какой-нибудь вариант типо такого:

@GetMapping("/defer")	
DeferredResult<String> getDefer() {
    DeferredResult<String> result = new DeferredResult<>();
    CompletableFuture.runAsync(() -> {
        try {
            Thread.sleep(30000);
            result.setResult("defer");
        } catch (InterruptedException e) {
            result.setErrorResult("Timeout");
        }
    }, mvcTaskExecutor());
    return result;
}

Так должно работать так как вы хотите. С async не работает, потому что спринг не умеет перехватывать вызовы @Async внутри одного класса, нужно чтобы обязательно был другой бин

Первый вопрос: git - распределенная система контроля версий, предполагающая, что все ветки будут синхронизироваться с остальными участниками. Поэтому бояться хранить в удаленном репозитории какие-то "не те" ветки не стоит, единственное, что нужно обговаривать условия именований (например feature - ветки можно именовать по шаблону feature/{task_id}). Кроме того git flow предполагает наличие feature - веток, release, hotfix etc. поэтому ограничиваться в этом плане не стоит.
Второй вопрос: это ветки, в которых идет доработка предыдущих релизов. Например, если в версии 3.2.2 нашелся баг, то чтобы пользователи с версией 2.5.5 получили это исправление тоже, коммит с исправлением попадает и в ветку 3.2.х (и выпускается релиз версии 3.2.3) и в ветку 2.5.х (и выпускается релиз версии 2.5.6). Это опционально, кому-то просто удобно разрабатывать так, но вы можете выбрать то, как удобнее именно вам и вашей команде