fix(IItem): make id and owner the only required properties of IItem

[jgravois]

AFFECTS PACKAGES:
@esri/arcgis-rest-common-types

ISSUES CLOSED: #171

[tomwayson]

nvm, I agree w/ travis on this one - can't make id required b/c when you're adding items you don't have one of those.

[jgravois]

whoops.

i didn't see any errors locally because i didn't run npm run build after making the change 🤕.

once everyone's happy i'll rebase and reword the commitizen message.

[coveralls]

Coverage remained the same at 99.43% when pulling b213fbd on patch171 into 20296ab on master.

[noahmulfinger]

@jgravois Looks like fixing the updateItem issue in #171 requires a more fine-grained approach. We should probably just make all IItem properties optional and then extend IItem whenever a function requires certain properties.

[tomwayson]

Good idea @noahmulfinger - I suggest something likeIUpdateItemParams which inherits from IItem

[jgravois]

We should probably just make all IItem properties optional

Agreed.

a perfect example of why is createItemInFolder().

it ignores item.owner entirely in favor of requestOptions.owner (or requestOptions.authentication.username)

i've tacked on another commit which includes the value in the decision tree (with more precedence than either of the other two sources).

if y'all are up for it, my preference would be to add a deprecation warning regarding requestOptions.owner and yank it entirely in v2.0.0

[jgravois]

after chatting w/ @tomwayson briefly i'm convinced that the correct order of precedence is

1. requestOptions.owner
2. requestOptions.item.owner
3. requestOptions.authentication.username

i did a little manual testing and confirmed that regardless of whether item.owner is omitted in the request or contains a value that doesn't match the url route, the REST API will overwrite with the appropriate JSON. i'm happy about that.

[jgravois]

ready for re-review (ideally from @tomwayson)

[jgravois]

removed a duplicate property present in the interface being extended.