File manifests encode empty link names.

### Checklist

- [X] This is a bug report, not a question. Ask questions on [discuss.ipfs.io](https://discuss.ipfs.io).
- [X] I have searched on the [issue tracker](https://github.com/ipfs/go-ipfs/issues?q=is%3Aissue) for my bug.
- [X] I am running the latest [go-ipfs version](https://dist.ipfs.io/#go-ipfs) or have an issue updating.

### Installation method

built from source

### Version

```Text
$ ipfs version --all
go-ipfs version: 0.12.0-rc1-8a88718ea
Repo version: 12
System version: amd64/linux
Golang version: go1.17.5
```

### Config

```json
N/A
```

### Description

I'm implementing a very low copy chunking + layout engine exporting `.car` and wondering why my CIDs are different.
This is because my IPLD nodes don't contain names when not needed.
This file for example:
Mine (expected):
```
$ ipfs block get bafybeig76jnqhurgk4uh57a7soykyi2pcr673tfiw72uvsp5neexgxnp2i | protoc --decode=PBNode ipld.pb
Data: "\010\002\030\222N \2000 \222\036"
Links {
Hash: "\001U\022 \262\307\016\013 77\r\204\370\260\332\315@\245\201[\375\243\251\237\232\'\013\364\272\314\305\213\226\315\310"
Tsize: 6144
}
Links {
Hash: "\001U\022 \311\254\220r?,\276\'\345\034\276v\311\322\177\321`\016\233\210\n<\3566\250*\365g\372\220l\304"
Tsize: 3858
}
```
IPFS (`#` comments added by me):
```
ipfs block get bafybeibpwnfexq45cqgf27w7wyzy2ebzgizwieushxt6jidzukyirnxss4 | protoc --decode=PBNode ipld.pb
Data: "\010\002\030\222N \2000 \222\036"
Links {
Hash: "\001U\022 \262\307\016\013 77\r\204\370\260\332\315@\245\201[\375\243\251\237\232\'\013\364\272\314\305\213\226\315\310"
Name: "" # <- EXTRA HERE
Tsize: 6144
}
Links {
Hash: "\001U\022 \311\254\220r?,\276\'\345\034\276v\311\322\177\321`\016\233\210\n<\3566\250*\365g\372\220l\304"
Name: "" # <- EXTRA HERE
Tsize: 3858
}
```
Both files load and work perfectly.
FYI, this a two leaf file with raw-leaves and that the root block.
This cost us 2 bytes per in-file-link.
Everything else (the leaves and unixfs's data match perfectly).

I know this is not really an IPFS bug but more an IPLD one.
However this is not unixfs since this is on the IPLD node object, and I don't know yet which code deals with that, so I'm reporting it here and will link elsewhere.

### Breaking hashes ?
I belive it would be nice to bundle a fix for this in the yet to be scheduled "big hash break update" (I think that how we should name such update).