Evgeny

Обычно выносят такой тип в отдельный пакет, делают тип приватным и публичную функцию New, возвращающую подготовленный объект.

//// users/users.go
package users

type user struct {
  name string
}

func New(name string) *user {
    u := user{
        name: name,
    }
    if name == "" {
        u.name = "Nobody"
    }
    return &u
}

///// main.go
package main

import "github.com/yourproject/users"

func main() {
    user := users.New("")
    ...........
}

Ровно такие же, как и не на вебсокет.
Если у вас nginx всё равно есть в цепочке, то легче доверить https ему, а на бэкенд переправлять через

client_max_body_size 0;
proxy_http_version 1.1;
proxy_pass http://your.websocket.backend/;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

В протобуфе придётся делать несколько полей, по одному на каждый тип сообщения. После получения айди типа, обращаться к нужному полю.

при успешном подключении добавляй в словарь/массив, при отключении удаляй оттуда, тогда все сведется к len
или если вообще не нужны экземпляры подключений, а просто счетчик - завел переменную, при подключении инкремент, при отключении - декремент

Это неважно.
Не следует "экономить на спичках" и соблюдать пустые ритуалы. Вы пишите приложение нормально, чтобы его понимали и нормально читали другие разработчики. Когда же дело доходит до оптимизации, Вы профилируете и смотрите где конкретно у Вас проблемы и затыки. Их и убираете.

Что же касается конкретно аллокаций, то всё не совсем так (вернее, совсем не так).
Аллокация - это выделение куска памяти в куче (heap), который потом должен быть убран сборщиком мусора. Именно потому это и считается ударом по производительности, так как добавляет работы как аллокатору, так и сборщику мусора.
Но использование := само по себе не включает/выключает использование аллокации. Оно лишь декларирует новую переменную.
Будет ли произведена аллокация зависит от другого. В первую очередь, от того какие Вы данные создаёте. Если это примитивный тип фиксированного размера, размещаемый на стэке (например int), то работы с кучей у Вас не будет вовсе, соответственно и аллокаций. Во вторую очередь, от такой магической штуки как escape analysis, которая может запросто разместить данные из кучи на стэке, если ей так того захочется, тогда аллокации у Вас происходить тоже не будет.

Давайте посмотрим примеры:

1. var i int
   i = 1
   i = 2

   
   0 аллокаций, так как i размещается строго на стэке.
   
   

2. i := 1
   i := 2

   
   0 аллокаций, так как i размещается строго на стэке.
   
   

3. i := new(Struct{1,2,3})
   i := new(Struct{3,2,1})

   
   2 аллокации, так как new разместит данные в куче и вернёт указатель на них. Но только если escape analysis не переместит это всё в стэк (что конкретно в данном случае достаточно вероятно).
   
   

4. var i *Struct
   i = new(Struct{1,2,3})
   i = new(Struct{3,2,1})

   
   2 аллокации, так как new все ещё разместит данные в куче и вернёт указатель на них.
   
   

Как Вы видите, := сам по себе никак к аллокациям не относится, и является лишь синтаксическим сахаром.

P.S. Давеча на Хабре была отличнейшая статья про стандартную библиотеку Go, показывающая что занятие преждевременными микрооптимизациями без профилирования - вполне себе бессмысленная затея.

А может вовсе и не взлом, а крик души?