korsamc

Да, самый простой вариант, это:
Пользователь отправляет нам на сервер логин+пароль.
Сервер сверяет с данными в БД, если всё хорошо, то генерирует большую случайную строку(Токен), которую добавляет как запись в БД (UserID, Token), после этого отправляет клиенту токен, чтоб тот установил у себя его в куки (заголовок Set-Cookie).
Теперь браузер клиента на каждый запрос будет отсылать на сервер куку и мы можем, обращаясь к БД на поиск строки из куки, получать данные о пользователе.
Но так как хранение в БД не всегда эффективно, токены хранят иногда в быстрых БД, таких как Redis или MemCached.

По поводу сессии:
Иногда, чтоб не ходить в главную БД на каждый запрос, некоторые данные выносят из главной БД(В тот же Redis, MemCached или даже просто в файл на диске с именем токена). Просто теперь, хранится не только токен, но и по имени токена сразу же получают некоторые данные, например, что у пользователя ID=42 и что он администратор.

Через какое то время удалять?

День, неделя, несколько часов, зависит от задачи.
Например, некоторые сайты хранят сессию сутки, но если нажать галочку "Запомнить меня", то срок может увеличится до недели или месяца.
Сервисы оперирующие с деньгами или чем-то, что может представлять ценность, делают сессии от 10 минут.

Лучше всего создать типа под Inline keyboard и маршалить из него

type InlineKeyboard [][]InlineKeyboardButton

type InlineKeyboardButton struct {
	Text         string
	Url          string
	CallbackData interface{}
}

Ты в wg добавляешь единицу, первая выполнившаяся горутина эту единицу отнимает, wg.Wait() разблокирует поток и main завершается. wg.Add нужно делать на каждую горутину, которую ты хочешь подождать

Также os.Exit завершает весь процесс. То есть, первая горутина, которая на него наткнётся, завершит всё

Ещё ты абсолютно бесконтрольно спавнишь горутины в бесконечном цикле. Используй адекватное количество горутин, которые работают одновременно и закидывай им таски через каналы

Почитай теорию ещё пару раз

А вот ещё прекрасная статья, которая поможет понять горутины и типичные примеры их использования

iptables:

*nat
-A PREROUTING -d 10.100.0.220/32 -p tcp -m tcp --dport 80 -j ACCEPT
-A PREROUTING -p tcp -m tcp --dport 80 -m set ! --match-set mac-allowed src -j DNAT --to-destination 10.100.0.220

*filter
-A FORWARD -i vlan1+ -j macallowed
-A macallowed -d DNS-сервер -p udp -m udp --dport 53 -j ACCEPT
-A macallowed -m set --match-set mac-allowed src -j ACCEPT
-A macallowed -j DROP

ipset:

create mac-allowed hash:mac hashsize 1024 maxelem 65536
add mac-allowed A0:4E:A7:55:44:33

Примерно так.
В nat prerouting трафик не из ipset разрешенных MAC-адресов заворачивается на хост с порталом.
И на портале надо в заголовке указать код 511, чтобы captive portal detection понимал, что это песочница и сам
открывал окно для дополнительных действий для подключения( хотя это не точно):

header('HTTP/1.1 511 Network Authentication Required', TRUE, 511);
header("Location: http://10.100.0.220/portal/index.php?step=1");

PS. Можно обойтись и без ipset, но с ним быстрее, когда записей станет много.

Попробуйте в *.pro файле указать:
LIBS += -ldl

Наверное, ошибка в том, что не "который встречается в нём N/2 раз", а "как минимум N/2 раз, где N - количество уникальных элементов"? Т.е. у вас ошибка в строгом сравнении.
if((vec.size()-1)/2.0 == mycount ) // <<------