To better answer this question:
Why 8 bytes?
Initially BLE standard defines 1 advertising packet or 1 scan response packet can carry max 31 bytes payload. (Now it has increased to 255.)
Within the 31-byte, the user can place multiple so called "AD Structure". 1 AD structure is organized as 1 length byte, 1 AD type byte, and N AD data bytes. As you might realized, 1 advScanStruct in our demo code is exactly this thing.
In most demos, there is advScanStruct[3]. The first element is AD Flags (length 1 + type 1 + data 1 = 3 bytes).
The second is a 128-bit UUID to indicate what service is supported. (length 1 + type 1 + data 16 = 18 bytes.)
This left 31-18-3 = 10 bytes for the third AD struct, which could be device name if you will. Or technically it could something else. See this link for other possibilities:
https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile/
So the storage for device name is only 10 - 1 length - 1 type = 8 bytes
What if 9 bytes or more?
If we want a device name more than 8 bytes, we could remove the 128-bit UUID advScanStruct to free up 18 bytes space, but then some phones cannot know what service your BLE device can offer.
Alternatively is to put the device name in scan response packet. This packet is the same as adv packets but only exchanged when doing scan request/response. And in most use cases this is not a problem.
So in this way the device name can be max 31 - 1 -1 = 29 bytes.
Shortened or Complete device name?
As it suggests, if your adv data carries full name, then use Complete Local Name (type 0x09 in the link above),
otherwise Shortened Local Name (type 0x08). Complete Local Name is the Bluetooth term, sometimes we just call it full device name.
Shortened name makes the adv packets shorter, but then the phone would have to make a connection to and read your GATT database to find out the Complete Local Name.
This is up to the user.
MAC Address and Privacy
Some company would put complete MAC address in the adv packet as a part of the full device name. This is handy in some ways. But please also be aware that other hackers can track your device, by just listening to the adv packets. As the unique MAC address is in the payload, it is easy to find out the geo location of a certain BLE advertiser device.
The BLE standard has a privacy feature which keeps changing the device address value in the air to avoid tracking. But as adv data is not encrypted, MAC address in advertising payloads can make BLE privacy ineffective.
Device Name in GATT Database
As Sebastian mentioned already, users can also create a GATT database with a primary service (service_gap), and inside the service put a characteristic device name. This value should be treated the same as Local Name in adv packet, but of course it is finally your phone OS to interpret and use these values.
In the phones I've tested (iOS and Android), when scanning device, the name in the list is the Local Name in the adv packets. After a connection, the phone OS would try to read Device Name in GATT database, and if that's successful, the displayed name would be replaced by this value.
