Rename Smb to SMB

[alexander-ding]

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:

/kind api-change

/kind bug
/kind cleanup
/kind design
/kind documentation
/kind failing-test
/kind feature
/kind flake

What this PR does / why we need it:
Improve naming consistency and adhere to Go best practices (using all caps when the name contains acronyms).

Which issue(s) this PR fixes:

Fixes #246

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

NONE

/cc @mauriciopoppe

[mauriciopoppe]

I saw === RUN TestNewSMBGlobalMapping in the unit tests and === RUN TestSMB --- PASS: TestSMB (20.37s) in the integration tests in both Github Actions and Prow.

I saw formatting errors that were in the output but the job didn't fail, could you find out why? https://github.com/kubernetes-csi/csi-proxy/actions/runs/3269029089/jobs/5376115868#step:4:40

[alexander-ding]

I saw === RUN TestNewSMBGlobalMapping in the unit tests and === RUN TestSMB --- PASS: TestSMB (20.37s) in the integration tests in both Github Actions and Prow.

Wait, what's wrong with that exactly? The former is a unit test (amongst some other unit tests in the original codebase). The latter
is the integration test.

I saw formatting errors that were in the output but the job didn't fail, could you find out why? https://github.com/kubernetes-csi/csi-proxy/actions/runs/3269029089/jobs/5376115868#step:4:40

These formatting errors have been happening since long ago (see this old job). I think what's happening is that most developers are using Linux/Darwin machines, and gofmt on these machines use \n endings, whereas the GH action runs on a Windows machine, where gofmt looks for \r\n endings. See this GH issue.

Apparently, that's a feature, not a bug. We can either (a) remove go-fmt checks entirely or (b) migrate them into a separate GH action job running on a Linux machine. I'm leaning towards the latter, though this might make life difficult for developers using Windows machines. Regardless, we'd want to maintain a consistent line ending across the code base.

The reason why this wasn't failing the GH action is because the default behavior is to continue execution (and base the result of the GH action based on the last executed command). See this post.

[alexander-ding]

What I recommend we do right now is to

1. Ignore the formatting error and merge for now.
2. Track the need to refactor the GitHub action job (and the Makefile) in another issue. We can talk about which way to refactor is best as well.

[mauriciopoppe]

Got it, thanks for pointing out the default behavior of Github Actions, yes it looks like this error has been happening for some time already. Changing release-tools is not that easy as the code is common to many kubernetes-csi repos and comes from https://github.com/kubernetes-csi/csi-release-tools/

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alexander-ding, mauriciopoppe

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mauriciopoppe]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment