Vindicar

1. Основы выбранного языка. Понятие класса, экземпляра класса, метода и т.п. Структуры данных - для питона это списки, словари, кортежи в первую очередь. Пишешь простые примеры, пусть даже на уровне крестиков-ноликов.
2. Основы сетевых приложений. Что такое сокет, что такое соединение, как оно устанавливается, как передаются и принимаются данные, как соединение разрывается. Совсем вглубь забираться не надо. Пишешь простой чат на две программы, одна сервер, другая клиент.
3. Протокол HTTP как таковой. Что такое запрос, что такое ответ, что такое заголовки, что такое тело. Пробуешь скачать вебстраничку и сохранить её в файл, используя тот же requests.
4. JSON как способ представления объектов. Стандартный модуль json в питоне. Пробуешь какое-нибудь открытое API, которое JSON отдаёт, экспериментируешь с ним.
5. Разбираешься с вебсокетами.

Открой доки и почитай. CancelledError выбрасывается в корутине, когда она завёрнута в таск через create_task() и на этом таске вызван метод cancel(). Это позволяет прервать выполнение корутины через выбрасывание специального исключения. Исключение не наследуется от Exception, поэтому обычный try-except его не ловит, если только специально не указать try ... except CancelledError. Так сделано, потому что при выходе через всплывание исключения будут отрабатывать все нормальные питоновские механизмы: блоки finally, блоки with и так далее.
Я полагаю, команда на остановку бота делает cancel() на его главной корутине, скорее всего запущенной внутри start_polling(). Это исключение всплывает в твой main(). Но поскольку main() выполняется в asyncio.run(), то исключение всплывает туда. Это исключение не имеет особого смысла вне asyncio, так что я полагаю, run() ловит это исключение и вместо него выбрасывает KeyboardInterrupt() как ближайший не-асинхронный эквивалент. Это исключение всплывает на верхний уровень и останавливает интерпретатор.

Ты можешь ловить CancelledError в main(), чтобы спокойно завершить работу бота. Ну или ловить KeyboardInterrupt() в теле скрипта, на вызове asyncio.run().

Гугли finite state machine (FSM) для библиотеки, которой пользуешься.

У тебя будет проблема в том, что во второй файл надо будет передать объект bot, которого, скорее всего, не будет на момент импорта этого файла.
Есть не слишком изящный, но простой способ.

# imported_file.py
import telebot
from telebot import types

def setup(bot):  # setup() принимает бота и прочее как параметры.
    # да, прописываем обработчики прямо внутри setup()
    # но вот глобальные переменные здесь прописывать не стоит
    @bot.message_handler(content_types=['text'])
    def get_text_messages(message):
        ...

# main_file.py
import telebot
from telebot import types
import time

import imported_file

bot = telebot.TeleBot("ТОКЕН")
# убедись, что setup() вызывается строго один раз для каждого дополнительного файла!
imported_file.setup(bot)  
...  # дальше работаем как обычно

Этот вариант позволяет загрузить файл уже в ходе работы бота, но не предусматривает возможности выгрузить файл на ходу. Впрочем, не все библиотеки позволяют отвязать обработчик от события, так что это не только проблема этого подхода.

1. Записать в переменной ID получателя.
2. Разобраться, как отправить сообщение по заранее известному ID.
3. Разобраться, как пользоваться aioschedule.

Вместо text в callback_query_handler() укажи функцию, которая принимает CallbackQuery и возвращает True, если надо обработать данный запрос, и False, если нужно поискать другой обработчик. Для ускорения можешь все коды запросов в БД пометить отдельным префиксом (например, пусть они начинаются с "db_"), чтобы сразу отсечь посторонние коды.
Просто погугли callback_query_handler, увидишь что-то типа lambda callback_query: True - это означает "принимать любые коды запроса". Но ведь можно True возвращать не всегда.