Rename generic publickey import function

[lukpueh]

Fixes: # -

Description of the changes being introduced by the pull request:

Rename "public_key" to "publickey" for consistency with other interface key import functions.

This commit also fixes a typo in an error message, removes unnecessary module paths and adds a note to the function docstring to inform about the shortcoming of the generic function.

Note: We might want to revisit said shortcoming in a future interface enhancing PR (also see #251). For now we primarily want to sort out in-toto/in-toto#80, of which this PR is a part.

Please verify and check that the pull request fulfils the following requirements:

• The code follows the Code Style Guidelines
• Tests have been added for the bug fix or new feature
• Docs have been added for the bug fix or new feature

[coveralls]

Coverage remained the same at 98.878% when pulling d7dfca6 on lukpueh:rename-import-pubkey into 0ec854b on secure-systems-lab:master.

[SantiagoTorres]

LGTM. Thanks!

[joshuagl]

This is a breaking change. Is it worth continuing to provide the old name for a deprecation period?

[SantiagoTorres]

You mean leave a facade for it for a deprecation period? that sounds sensible. Probably with a printed warning would be ideal.

[trishankatdatadog]

Yeah, there are some nice @deprecated decorators we could use to clearly mark such functions and emit warnings, etc

[joshuagl]

You mean leave a facade for it for a deprecation period? that sounds sensible. Probably with a printed warning would be ideal.

Yes, that's what I meant. Thanks for clarifying.

As we're building up to major releases of in-toto and tuf I'd like usm as a coalition of projects, to try and improve our maintenance discipline.

[lukpueh]

I generally agree, however the function renamed in this PR was only just introduced 2 weeks ago (see #278) and has not been part of any release. So I think we're good with out deprecation strategy in this scenario.

That said, I'm planning to soon submit a PR that does change the interface by adding additional optional arguments that also change the default behavior. I hope you all can weigh in there as well.

[joshuagl]

I generally agree, however the function renamed in this PR was only just introduced 2 weeks ago (see #278) and has not been part of any release. So I think we're good with out deprecation strategy in this scenario.

Sounds good to me, thanks for providing the extra context.

That said, I'm planning to soon submit a PR that does change the interface by adding additional optional arguments that also change the default behavior. I hope you all can weigh in there as well.

Absolutely.