gitlab/attributes: Drop default values for `omnibus-gitconfig`

What does this MR do?

The Gitlab['omnibus-gitconfig']['system'] attribute used to contain Git configuration that was subsequently used by Gitaly. This was done by writing its config entries into the global gitconfig file so that they were picked up by all Git commands.

This has proven to be insufficient in the context of Gitaly, which needs a lot more fine-grained control over the exact Git configuration it uses when spawning Git commands. One point in case was the deprecation of the old core.fsyncObjetFiles configuration, which if present caused us to print user-visible warnings.

We have since moved all default Git configuration into Gitaly itself, which thus does not need any external Git configuration by default anymore. Furthermore, we have implemented a mechanism in Gitaly to just plain ignore the global gitconfig file -- instead, non-default Git configuration needs to be written into Gitaly's config.toml.

In Omnibus though we still carry legacy defaults that were used for the Git configuration back when Gitaly didn't yet knew to set up its own defaults. As we know to strip those defaults when writing Gitaly's config.toml they don't apply at all in that context, but we still write them into the global gitconfig file. Consequentially, these defaults apply to all Git commands not spawned by Gitaly itself. Arguably though this is not required:

- `pack.threads=1` controls how many packs should be used when
  writing Git packfiles. This was added to limit the amount of
  resources a single Git process could use in the context of Gitaly.

- `receive.fsckObjects=true` asks Git to perform consistency checks
  for objects when serving a push. We should never accept pushes
  into Git repositories outside of Gitaly anyway.

- `receive.advertisePushOptions=true` asks Git to advertise the
  availability of push options to clients when serving a push.
  Again, we should never accept pushes into Git repositories outside
  of Gitaly.

- `transfer.hideRefs` hides various internal namespaces when serving
  fetches and pushes. Same as above, we should not accept pushes
  into Git repositories outside of Gitaly.

- `repack.writeBitmaps=true` asks Git to write bitmaps via
  git-repack(1). This would even be wrong if git-repack(1) was to be
  executed in a repository that is connected to an object pool.

- `fetch.writeCommitGraph=true` asks Git to write commit-graphs when
  fetching into a repository. This data structure is used to speed
  up various operations. There is no reason to enable this globally.

- `core.alternateRefsCommand="exit 0 #"` will disable listing
  alternate references when a repository is connected to another
  repository. There is no reason to disable this globally.

- `core.fsyncObjectFiles=true` is the only one that is debatable as
  it enables calling fsync(3P) when writing objects into a Git
  repository. This option has been deprecated in Git v2.36.0 though
  and causes deprecation warnings to be printed on every invocation
  of Git. So if at all, we would want to set `core.fsync` nowadays
  to enable this code again. On the other hand though there should
  be no manual commands that write Git objects into repositories
  controlled by Gitaly in the first place as that is not supported.

Drop all the default values. All of these config entries are managed by Gitaly already, have no obvious purpose when running Git commands globally and add complexity and confusion around what the actual configuration is now.

This is another intermediate step to make !6447 (closed) simpler.

Related issues

Related to #6800 (closed).

Related to gitaly#4230 (closed).

Part of &8069 (closed).

Related to #6889.

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion

Required

• Merge Request Title, and Description are up to date, accurate, and descriptive
• MR targeting the appropriate branch
• MR has a green pipeline on GitLab.com
• Pipeline is green on dev.gitlab.org if the change is touching anything besides documentation or internal cookbooks
• trigger-package has a green pipeline running against latest commit

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes
• Documentation created/updated
• Tests added
• Integration tests added to GitLab QA
• Equivalent MR/issue for the GitLab Chart opened