WHERE 
(
    `phone1` IN ('83519025115','87051036787', '88142531260', ...) 
  OR
    `phone2` IN ('83519025115','87051036787', '88142531260', ...)
)

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

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

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

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

На GO, "православный" стек, это стандартный пакет net/http + какой нибудь внешний роутер, например chi, либо вообще не http/rest, а gRPC (если мы говорим об API).
Для БД чистый SQL, максимум какой нибудь маппер на структуру, типа sqlx(можно ещё использовать sql builder, но в IDE Goland хорошая поддержка чистого sql).

ORM очень не советую, есть конечно gorm(генерирует запросы не эффективно, N+1 при связях), для мелких проектов хватит, но вот со сложными запросами любая ORM не справляется.
Я категорически против ORM, так как за всё время моей работы в вебе, в любом проекте, самым слабым звеном всегда была ORM(долбит кучей запросов БД, когда на чистом sql это 1-2 запроса), либо программист, вместо того, чтобы написать запрос вида "SELECT SUM(amount) FROM book WHERE author = 'Petya'", достаёт все записи и суммирует это в коде(делает работу за БД + тратит ресурсы БД на чтение данных с диска и передачу их по сети).

Не нужно использовать фреймворки, это не даст опыта написания на go(как и в большинстве языков).
Go используют, где производительности других решений не достаточно, или нужна многопоточность, что фреймворки так себе обеспечивают.
Шаблоны в go практически не использую, пишу фронт на vuejs и обращаюсь к go api.
Есть генераторы документаций, но я тут не посоветую, их нужно тестировать отдельно, у каждого есть свои плюсы и минусы, сам использую другое решение(опишу в конце).

Самое главное, побыстрее понять, что на go нужно писать как на go, а не так как привыкли в других языках, потому-что, в нём нет привычных классов, строгая типизация, процесс живёт долго и могут быть race condition(гонка состояний) при многопотоке(веб сервер многопоточный), поэтому о подходах из php советую поскорее забыть.

В своих проектах(в проде), использую go только как сервис предоставляющий апи. Недавно начал использовать grpc-gateway(так как использую gRPC, но так же необходимо делать API доступное через web), проект позволяет описать всё что необходимо в proto файлах (см. gRPC), сгенерировать модели и обёртки под большенство языков + документацию в OpenAPI 2.0. Это не фреймворк, это обёртка над стандартным net/http, которая сразу валидирует и маппит данные на структуру.

Коротко:
Для новичка, советую забыть про фреймворки(они не помогут в изучении) и ORM(не эффективно).

Использовать для веб сервера:
net/http - встроен в го
chi(проще) или gorilla/mux - роутер

Для взаимодействия с БД:
sqlx - обёртка над стандартным пакетом sql, но позволяет сразу считывать данные в структуру, без ручного сканирования.

Чтобы вернуть nil, нужно чтобы тип был ссылочным
func Start() (*RestResponse, error)

либо вы можете вернуть ошибку так:

if err != nil {
  return RestResponse{}, err
}

json.Unmarshal использует массив байт, а json.NewDecoder это потоковый парсер, которому не нужно сразу хранить в памяти все данные для парсинга.

Для парсинга json из файла или из запроса, я бы советовал json.NewDecoder, так как он будет меньше потреблять памяти (не нужно заранее считывать в память массив байт).