Remove implementation of contact flows

[gbrodman]

Now that we have transitioned to the minimum dataset, we no longer support any actions on contacts (and by the time this is merged / deployed, all contacts will be deleted). We should just throw an appropriate exception on all contact-related flows. We don't delete the flows themselves, so that we can have an appropriate error message.

We also keep all the flows and XML templates around individually for now because we may be required to continue to differentiate the requests in ICANN activity reporting (e.g. srs-cont-create vs srs-cont-delete) as well as in the interest of reducing change size

---

This change is 

[CydeWeys]

@CydeWeys made 2 comments.
Reviewable status: 0 of 35 files reviewed, 2 unresolved discussions (waiting on @gbrodman).

---

core/src/main/java/google/registry/flows/picker/FlowPicker.java line 138 at r1 (raw file):

            case ACK -> PollAckFlow.class;
            case REQUEST -> PollRequestFlow.class;
            default -> UnimplementedFlow.class;

Why this change?

---

core/src/main/java/google/registry/flows/contact/ContactTransferRequestFlow.java line 43 at r1 (raw file):

  @Override
  public EppResponse run() throws EppException {
    throw new ContactsProhibitedException();

Can you go one step further and have a ContactsProhibitedFlow (or similar name) that provides this implementation, and then all the other contact flows can simply look like this?

public final class ContactTransferRequestFlow implements ContactsProhibitedFlow {}

At that point you don't really even need the implementations, right? You would just have ContactsProhibitedFlow itself be the final implementation, and have FlowPicker just use that for every contact flow?

[gbrodman]

@gbrodman made 2 comments.
Reviewable status: 0 of 36 files reviewed, 2 unresolved discussions (waiting on @CydeWeys).

---

core/src/main/java/google/registry/flows/contact/ContactTransferRequestFlow.java line 43 at r1 (raw file):

Previously, CydeWeys (Ben McIlwain) wrote…

Can you go one step further and have a ContactsProhibitedFlow (or similar name) that provides this implementation, and then all the other contact flows can simply look like this?

public final class ContactTransferRequestFlow implements ContactsProhibitedFlow {}

At that point you don't really even need the implementations, right? You would just have ContactsProhibitedFlow itself be the final implementation, and have FlowPicker just use that for every contact flow?

see the PR description, I think we still want the flows themselves around for logging purposes -- as far as I can remember, the official language ICANN says is that we must provide the numbers of, e.g. contact creates that we "respond to" -- it doesn't say anything about the type of response.

We can definitely do the abstract class though.

---

core/src/main/java/google/registry/flows/picker/FlowPicker.java line 138 at r1 (raw file):

Previously, CydeWeys (Ben McIlwain) wrote…

Why this change?

Poking around the code and the default isn't necessary any more with the Java switch changes

[CydeWeys]

@CydeWeys made 1 comment and resolved 2 discussions.
Reviewable status: 0 of 36 files reviewed, all discussions resolved.