Add kpro_auth_backend:auth/8 to support passing handshake vsn

[starbelly]

This PR changes kpro_auth_backend to export auth/8 vs auth/7 to support passing the handshake version to a callback module. auth/8 will check to see CallbackModule exports auth/7, if it does not auth/6 on the callback module will be called for backwards compat.

As for the placement of the handshake vsn arg in function head, no strong feelings. I would even go so far as to suggest passing a map or a record to the callback module, but that doesn't have to be done in this PR either, unless we're open to the idea and would like to avoid future churn. An example of what the might look like can be seen here : https://github.com/kafka4beam/brod_gssapi/blob/51be03dcbcaa48cd77edcda3e8e75ca5e20123e8/src/brod_gssapi.erl#L94. However, we'd want to support a private key where callback modules can stuff in k/vs relevant to their context.

[kjellwinblad]

Looks good to me. I agree that passing the version in a map would be more future safe so I think we can go for that option. Let @zmstone have a look as well before you merge as he is more familiar with the code.

[zmstone]

Looks good to me. I agree that passing the version in a map would be more future safe so I think we can go for that option. Let @zmstone have a look as well before you merge as he is more familiar with the code.

I think this is good.

[starbelly]

Looks good to me. I agree that passing the version in a map would be more future safe so I think we can go for that option. Let @zmstone have a look as well before you merge as he is more familiar with the code.

I think this is good.

To be clear, are we in favor of add auth/1 here?

[zmstone]

Looks good to me. I agree that passing the version in a map would be more future safe so I think we can go for that option. Let @zmstone have a look as well before you merge as he is more familiar with the code.

I think this is good.

To be clear, are we in favor of add auth/1 here?

Sorry. I meant this current impl looks good.
However if we can foresee now there will be more args in the future (like the private key mentioned in pr description) then maybe a map makes sense
— note though, SaslOpts was designed to be an opaque term for extra args passing through kafka_protocol

[starbelly]

@zmstone sounds good. I think all changes that need to be made have been made, but let me know if other wise. Will squash and merge on your approval.

[zmstone]

released 4.1.0