Send a registration cancelation request, where the `remove' element is
NOT the only child of the `query' element, then wait to receive a
failure response. See table 1, section 3.2, XEP 0077.

Presumably, if inband registration is not enabled, then cancelatio is
not possible. Make sure Mongoose sends an error stanza. Note: does not
test for a particular error case.

Test that error stanzas for user registration and cancelation contain
the correct child elements. Move user creation and deletion into the
test case callbacks.

Test that Mongoose responds with the failure stanzas given XEP 0077
upon a bad cancelation request. Changing the configuration in the
"not-allowed" test should correspond better with the XEP: ALL users
are denied cancelation, rather than just stopping the the module.

The tests don't fail in quite the right way, so this is [WIP].

Change and restore the `mod_register' configuration as needed, resolve
test initialisation and termination issues, and change to include just
two helpful "printf" calls (really `ct:pal/2').

This addition tightly couples these tests with Mongoose.

Test for the `type' and namespace attributes in the error stanzas for
bad cancelation requests.

Change LHS `ok' to `{atomic, ok}' when changing configuration using
dynamic_modules:stop/2.

As this was not immediately clear.

Change `case' clauses for `set' and `get' IQs into procedure
clauses. One procedure to do it all meant deeply nested clauses.

Make sure the `query' element is the only one in the IQ stanza.

This commit retains logging for debug purposes.

This is for debugging.

Use a better name.

Add a test case to make sure that registration with an empty password
fails as specified in XEP 0077.

This procedure is more general in two ways: (1) change any option by
name, and (2) insert an option instead of just changing one that's
already there (`lists:keystore/4' combines an `append' and a
`replace'). Then, the `restore_mod_register_options/1' procedure does
cleanup, removing the module's option list from the test suite's
configuration list, so that we can change the configuration again and
again in a clean way.

A registration request with an empty password field will trigger the
correct error response when the password strength is non-zero.

Mongoose may well send the correct error response, but let's make sure
it doesn't do the wrong thing, too.

Don't build completely blank JIDs, as they need a "host" part at the
very least, just to remove them before sending the response.

Check that registration (and cancelation) are allowed before
proceeding, otherwise send an error response.

Move necessary agruments out of the "extras".

Move necessary agruments out of the "extras".

Move necessary agruments out of the "extras".

That is: `Sender'/`Receiver' ---> `From'/`To', and `Stanza' ---> `IQ'.

Also rename the procedure that helps to switch on the children of the
"query" element and use more informative names for the atoms which are
returned.

When someone has authenticated, i.e. they are already registered,
Mongoose should respond with a `registered' IQ query element.

Matches will succeed when changing password: we were comparing the
sender of a stanza to a JID that hadn't been formatted according to
XMPP guidelines.

NOTE: This test fails until a fix to Mongoose is made.

Since the password change is an IQ request, even though XEP 0077 does
not describe this, we test for an error response.

The procedure in question had an empty string (i.e. "") as a pattern
in its head, but it's meant to be a binary (i.e. <<"">>), so add this
clause.

The calls made inside `*_per_testcase(null_password, _)' simply
shouldn't be necessary to test for an error response when a client
tries to register with an null password.

We were matching only on an empty string when we really need to match
on an empty binary.

Test for a <resource-constraint/> error-response after making inband
registration requests in quick succession NOT just that we receive an
error-response. The second paragraph of section 3.1.1 of XEP 0077 may
suggest using a <not-acceptable/>, see comment in test for more
detail.

Mongoose should restrict the number of registrations, regardles of a
client's recent success or failure, within a time period.

This makes it more clear that the timers are prerequisites for both
tests.

An "error" stanza will in fact produce a "failed_to_register", not a
"bad_response".

This concerns changes to the `{access, register, global}' variable,
used for inband registration.

Assert timeouts have expired before much of the registration process
begins: this'll make sure that registration requests are constrained
within a given time period, regardless of a client's recent
registration success or failure. It discriminates clients using their
IP address.

We use the Erlang binary internally.